On Oct 28, 2003, at 4:07 PM, [EMAIL PROTECTED] 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.
