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 ___________________________________________________________________________ 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
