On Fri, Sep 4, 2015 at 11:42 AM, Hadriel Kaplan
<the.real.hadriel@xxxxxxxxx> 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@xxxxxxxxxxxxx>
> Archives: https://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe