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: