ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
July 17th, 2024 | 10:00am-11:55am SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 12257] CIP: Info column is set differently depending on wh

Date: Mon, 14 Mar 2016 02:45:15 +0000

Comment # 9 on bug 12257 from
(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.