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

Wireshark-dev: [Wireshark-dev] using wmem in wiretap

From: Hadriel Kaplan <the.real.hadriel@xxxxxxxxx>
Date: Fri, 4 Sep 2015 11:42:27 -0400
Howdy,
I've begun changing wiretap to enable us to handle pcapng files fully,
as described in:
https://wiki.wireshark.org/WiretapPcapng

One of the tangential issues I've hit is the memory management of the
various SHB/IDB/etc. structs/members. The previous model for wiretap
was somewhat mixed: wiretap internally handled cleanup of things in
the wtap struct, but not for wtap_dumper. This resulted in a lot of
tedious and error-prone g_free'ing calls in the applications using
wiretap, and often had leaks. (in fact, I'm pretty sure there are
still various mem leaks today)

Originally I thought wiretap should just be in charge of handling
cleanup all itself - but that isn't as easy as one would think, given
various error scenarios and unknown block support.

So now I'm thinking perhaps it should use the wmem framework - give
each wtap/wtap_dumper instance its own wmem pool, and all
blocks/members are created using it, and it's all auto-cleaned up on
file closure.

Does that sound reasonable? Or is it overkill?

The one big issue I see is that currently wmem is in epan, and part of
libwireshark. But there's nothing about it that appears to be
epan-specific, other than a few global singleton pools it maintains in
wmem_scopes.c. As far as I can tell, though, those are effectively
just specific accessor clients of the wmem "library" and could be
separated from wmem - the rest of wmem could be used by anyone if it
were separated out of libwireshark. Right?

-hadriel