Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-dev: Re: [Wireshark-dev] g_mem-chunk_destroy does not free memory for GLib > 2.8

From: Bill Meier <wmeier@xxxxxxxxxxx>
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