Re: g_mem-chunk_destroy does not free memory for GLib > 2.8

[Bill Meier <wmeier () newsguy com>]

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