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...