On Oct 28, 2003, at 4:07 PM, sford@xxxxxxxxxxxxx wrote:
I found two minor memory leaks using "valgrind" (a good malloc
debugging
tool; see http://developer.kde.org/~sewardj/ for info).
The tool currently tells me that there aren't any more on-going leaks.
Yet, the longer it runs (with a read filter), the more memory it
consumes. Does anybody have any idea why? Does the read filter
matching code generate a linked list of structures - parse trees
perhaps?
No. Parse trees are discarded when we're done with the packet.
Something that doesn't get cleaned up with: epan_dissect_free() and
clear_fdata() that is...
Yes, there's the request/response data structures you later found;
there are also data structures used when reassembling packets, and
probably other bits of persistent state as well.
Here's the diff -u output for files packet-diameter.c
Checked in, with some changes.
and packet-snmp.c:
The only leak I could see is one where we don't free "variable_oid" -
in all other cases, we free the variable in question (for all the
variables for which you've changed the handling). I've checked in a
change to plug that leak - using CLEANUP_PUSH and CLEANUP_CALL_AND_POP,
so that we don't leak "variable_oid" if "snmp_variable_decode()" throws
an exception due to running out of packet data.