On Sat, Jul 6, 2013 at 2:05 PM, Evan Huus <eapa...@gmail.com> wrote: > This morning, wmem finally hit the point that I was able to land some > changes to reduce leaks when calling epan_cleanup(). Yesterday, > running valgrind on 'tshark -v' showed over 500KB of leaked memory. > Now it shows 1,722 bytes. >
WOW! > Cleaning up those last few leaks will be enormously useful, both for > spotting "real" leaks (we might even be able to fuzz-test with > leak-checking some day!) and to make epan behave more like an actual > library. > > However, most of the remaining leaks aren't in dissector code but in > subsystems which I know less about, so I am not as confident that > simply using epan-scoped memory is the right thing to do. If you're on > a platform with valgrind, you can see the remaining leaks by running: > > ./tools/valgrind-wireshark.sh -l -n > > If not, here's a brief summary of which subsystems are still problematic. > > - preferences (a lot of small string leaks, mostly in > pre_init_prefs.part.3 and register_string_like_preference) > > - xml parser (I cleaned up the xml dissector, but the lemon grammar > itself seems to be leaking) > > It is actually in the dtd loader, not in the grammar itself. These are mine and my memory still holds that I deliberatly left them there as every time I tried to fixed I got something else broken, the code for loading the dtd has to be refatored to make sure we know if we can free these items, currently if you try to free them you end up freeing something wrong. I left them there as they are not while running but just a few blocks leaked at start. - user-accessible tables (various leaks in functions called from > uat_load_lex in uat_load.l) This most probably are mine but diversely from the dtd ones I was not aware... Another una-tantum leak BTW, not incremental while running. - oids_init > More code of mine... yet some more una-tantum leaks at init... It looks like I made a habit then... > > - capture_column_init_cb > > Feel free to ping me for more details (including stack traces) if you > want to help hunt down some leaks. > > Cheers, > Evan > ___________________________________________________________________________ > Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> > Archives: http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe > -- This information is top security. When you have read it, destroy yourself. -- Marshall McLuhan
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev@wireshark.org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
