[Luis EG Ontanon <luis@xxxxxxxxxxx>]

On Sat, Jul 6, 2013 at 2:05 PM, Evan Huus <eapache@xxxxxxxxx> 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@xxxxxxxxxxxxx>
Archives:    http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe

--
This information is top security. When you have read it, destroy yourself.
-- Marshall McLuhan