Wireshark mailing list archives
Re: Epan Memory Leaks
From: Luis EG Ontanon <luis () ontanon org>
Date: Sat, 6 Jul 2013 22:31:36 -0500
On Sat, Jul 6, 2013 at 2:05 PM, Evan Huus <eapache () 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-request () 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-request () wireshark org?subject=unsubscribe
Current thread:
- Epan Memory Leaks Evan Huus (Jul 06)
- r50415 change (was: Re: Epan Memory Leaks) Jakub Zawadzki (Jul 06)
- Re: r50415 change (was: Re: Epan Memory Leaks) Evan Huus (Jul 06)
- Re: Epan Memory Leaks Luis EG Ontanon (Jul 06)
- Re: Epan Memory Leaks Alexis La Goutte (Jul 07)
- r50415 change (was: Re: Epan Memory Leaks) Jakub Zawadzki (Jul 06)