Wireshark mailing list archives
Re: g_mem-chunk_destroy does not free memory for GLib > 2.8
From: Bill Meier <wmeier () newsguy com>
Date: Thu, 15 Oct 2009 16:43:14 -0400
Bill Meier wrote:
Even tho (in theory) most of the GMemChunks have been fixed, I'm still looking at a large memory leak someplace when I repeatedly reload a iax2/h223 capture file. Related to defragmentation ???
OK: (blinking in the bright sunlight as I emerge to the surface from the cave .....) Progress report: 1. It appears that there are at least several related memory leaks associated with reloading a file and having to do with defragmentation in reassemble.c Basically: after fragment_table_init & reassembled_table_init: a. fragment_data structs in the "fd lists" pointed to from the fragment_tables and reassembled_tables hashes are not freed; b. fragment_key structs pointed to from the fragment_tables hash are not freed. The code using GMemChunks freed these structs in reassemble_cleanup using g_mem_chunk_destroy. This hasn't worked since GLib 2.10 when g_mem_chunk_destroy stopped actually freeing memory. (Using g_slice doesn't change things since the code assumes that the structs can be but need not be freed individually). The lossage: mostly fragment_data_structs: 32-bytes * number_of_fragments_in_a_capture. Using se_alloc for these structs isn't the right answer because currently se_free_all is being called *before* the loop through all the dissector "registered init" fcns. (Also: fragment_key structs sometimes are individually freed). I've found at least one case wherein se_alloc'd memory is referenced after it's been freed. (I think this case just happens to work because the memory wasn't yet reassigned). I'm leaning towards the following: Free the fragment_data structs and etc in fragment_table_init and reassembled_table_init (similar to fragment_delete). (One has to be careful about doing so for the reassembled_table since an fd-chain can/will appear multiple times in the reassembled hash). Comments welcome.... 2. On a separate note: packet-iax2.c has a problem in that fragment_chains (and the associated pointed-to fragment data buffers) in the "call-associated" fragment_tables appear to never be freed when a capture file is (re)opened. Bill ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Re: g_mem-chunk_destroy does not free memory for GLib > 2.8 Bill Meier (Oct 09)
- Re: g_mem-chunk_destroy does not free memory for GLib > 2.8 Bill Meier (Oct 10)
- Re: g_mem-chunk_destroy does not free memory for GLib > 2.8 Kovarththanan Rajaratnam (Oct 11)
- Re: g_mem-chunk_destroy does not free memory for GLib > 2.8 Kovarththanan Rajaratnam (Oct 11)
- Re: g_mem-chunk_destroy does not free memory for GLib > 2.8 Bill Meier (Oct 11)
- Re: g_mem-chunk_destroy does not free memory for GLib > 2.8 Anders Broman (Oct 12)
- Re: g_mem-chunk_destroy does not free memory for GLib > 2.8 Bill Meier (Oct 12)
- Re: g_mem-chunk_destroy does not free memory for GLib > 2.8 Bill Meier (Oct 15)
- Re: g_mem-chunk_destroy does not free memory for GLib > 2.8 Jeff Morriss (Oct 15)
- Re: g_mem-chunk_destroy does not free memory for GLib > 2.8 Bill Meier (Oct 15)
- Re: g_mem-chunk_destroy does not free memory for GLib > 2.8 Jeff Morriss (Oct 20)
- Re: g_mem-chunk_destroy does not free memory for GLib > 2.8 Bill Meier (Oct 20)
- Re: g_mem-chunk_destroy does not free memory for GLib > 2.8 Bill Meier (Oct 11)
- Re: g_mem-chunk_destroy does not free memory for GLib > 2.8 Bill Meier (Oct 19)
- Re: g_mem-chunk_destroy does not free memory for GLib > 2.8 Jaap Keuter (Oct 12)