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