Wireshark-dev: Re: [Wireshark-dev] Memory leak
From: Jeff Morriss <[email protected]>
Date: Tue, 21 Aug 2007 18:33:36 -0400
Didier wrote:
On Thu, 19 Jul 2007 14:16:49 -0400, Jeff Morriss wrote
Didier wrote:
Hi,

1) It seems that since some glib 2.0 version g_mem_chunk_destroy doesn't
free
The docs certainly seem to indicate that the memory should actually
be freed:

http://www.gtk.org/api/2.6/glib/glib-Memory-Chunks.html#g-mem-chunk-destroy

and my (basic) attempt to follow the code goes down to
g_slice_free1() which appears to at least _try_ to free the memory.
Am I missing something?
In my understanding now g-mem-chunk-destroy only free the mem chunk object
(aka sizeof  structure g_mem_chunk) not the allocated memory as with gtk1.
You have to call g_mem_chunk_free for each allocated chunk.
Sorry, I just didn't have time to come back to this until recently.

I'm not seeing that leak, at least on Linux. Each atom is 131,072 bytes big. Reloading a 170,000 packet trace file many times does not show any growth in memory usage for Wireshark. If what you're saying is true then I should see /huge/ memory leak each time the file is reloaded, non?
Interestingly, I /do/ see "memory usage growth" on Windows as viewed by 
the Task Manager with the same file, but I think I read once not to 
trust what that tool tells you about memory usage...
2)COPY_ADDRESS is still misused in a lot of place it g_malloc address
space
but many don't free it.
There is (also) an SE_COPY_ADDRESS; is there any reason not to make
all COPY_ADDRESS calls seasonal?
One good reason is that the fragmentation/reassembly routines use 
COPY_ADDRESS and they _do_ clean up after themselves (and we probably 
want them to continue to do so to limit memory usage).
It makes sense for some but a lot of them are in taps code with a live time
between ep and se.
Some leaks are on every access cf. dissectors/packet-jxta.c
packet-jxta is storing the address in its conversation data--which 
should be "seasonal".  I just made it (and the rest of epan/dissectors/) 
use SE_COPY_ADDRESS (or, in some cases, SET_ADDRESS).
I'll have to look at the taps another day...