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.
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)
- user-accessible tables (various leaks in functions called from
uat_load_lex in uat_load.l)
- oids_init
- 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
