Wireshark-bugs: [Wireshark-bugs] [Bug 12257] CIP: Info column is set differently depending on wh
Comment # 9
on bug 12257
from Guy Harris
(In reply to daulis0 from comment #0)
> 1. proto_tree_add_subtree_format() allocates memory (a few calls down).
proto_tree_add_XXX, for all values of XXX, allocates memory *if* a protocol
tree is being constructed.
> Maybe the Qt build has different memory pool sizes than Gtk version?
No.
> 2. If the memory pool sizes are the same, maybe the usable memory sizes for
> packet data are less in the Qt version, because Qt uses more memory?
If you run out of usable memory in a proto_tree_add_XXX routine,
Wireshark/TShark/etc. crashes, because they use the GLib memory allocator,
which, by default, crashes when it runs out of memory.
Even if we *didn't* use such a memory allocator, if they ran out of memory,
they'd abort the entire dissection process, and probably end up closing the
current capture and popping up a dialog that says "sorry, there isn't enough
{address space, swap space+main memory} to handle that capture file"; it
wouldn't just decide to return NULL from such a low-level routine.
> 3. Wireshark seems to parse the packet multiple times (when opening,
> applying filters, etc).
Yes. Add "when displaying the columns for a visible packet row" to that list.
> The Qt version does extra passes, calling
> proto_tree_add_subtree_format() more than the Gtk version,
It might happen to do so in the current release; future releases may differ.
Never ever ever ever ever ever ever assume that a proto_tree or proto_item
pointer will never be null; it will be, if you were called with a null protocol
tree argument, which could happen if this *particular* dissection call doesn't
need to construct a protocol tree, and that could happen if *Shark is trying to
construct the column values.
> maybe this causes
> the memory pool to run out sooner? When I run the above steps in the Gtk
> version, proto_tree_add_subtree_format() is called 10 times. In the Qt
> version, proto_tree_add_subtree_format() is called 14 times.
If the memory pool had run out, you'd have gotten a crash. That's not what's
happening.
You are receiving this mail because:
- You are watching all bug changes.
