Wireshark mailing list archives

Re: using wmem in wiretap


From: Evan Huus <eapache () gmail com>
Date: Fri, 4 Sep 2015 13:29:09 -0400

On Fri, Sep 4, 2015 at 11:42 AM, Hadriel Kaplan
<the.real.hadriel () gmail com> wrote:
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?

Don't know enough about the "various error scenarios and unknown block
support" you mention to really say.

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?

Spot on. Moving wmem into wsutil (with the sole exception of
wmem_scopes.[ch]) is perfectly reasonable and probably pretty easy.

-hadriel
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe


Current thread: