On Fri, Sep 4, 2015 at 11:42 AM, Hadriel Kaplan <the.real.hadr...@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-requ...@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-requ...@wireshark.org?subject=unsubscribe
