Wireshark-dev: Re: [Wireshark-dev] g_mem-chunk_destroy does not free memory for GLib > 2.8
From: Bill Meier <wmeier@xxxxxxxxxxx>
Date: Fri, 09 Oct 2009 19:15:15 -0400
While working on bug #2375 I've found out (the hard way) what Didier reported in bug #3813:

"... in recent glibs g_mem_chunk_destroy doesn't free [memory] ...".

I'm guessing that this is true for any GLib > 2.8 (altho I haven't checked) since GSlice was implemented in GLib 2.10.

This means that any use of a current (recent) GLib GMemChunk with many entries can/will be a memory leak.

For example: I've a 40Meg capture file with NCP frames which causes memory allocation to increase by 20 M each time the file is reloaded (^R). (Loading the file results in 2 memchunks in the NCP222 dissector each with over 60K entries).

I note that the GLib doc (under GMemChunk) suggests using the slice allocator instead (g_slice_new & etc).

However, unless I'm missing something it seems to me that to free up (say) 60K slices requires a loop to call g_slice_free 60K times.

(g_slice_free_chain can be used if the slices are part of a linked list).

If there is no simple way to free up what may be an array of many multiple slices, I'm inclined to replace the use of GMemChunk (at least for those cases) by the use of GArray.

After a quick look, one concern I have is about constantly extending a GArray thus causing a copy each time. I note that it does seem that space for multiple entries can be pre-allocated. So: a wrapper for GArray could be coded which more or less does what I GMemChunk used to do. Or: does GArray have some builtin optimization ?


Comments ?
(or: what am I missing as to the best way to replace the use of GMemChunk ?).


Bill



The following GMemChunk usages look like memory leaks (eg: when file reloaded):
  ./epan/dissectors/packet-isakmp.c
  ./epan/dissectors/packet-mgcp.c
  ./epan/dissectors/packet-radius.c
  ./epan/dissectors/packet-sbus.c
  ./epan/dissectors/packet-teamspeak2.c
  ./epan/stream.c
  ./plugins/irda/packet-irda.c
  ./plugins/mate/mate_util.c

The following are OK:
  ./epan/proto.c:455  ; Used for all GLib versions: mem leak @
                      ;  proto_cleanup ?
                      ; Benign since proto_cleanup called only @ exit ??
  ./epan/reassemble.c ; uses g_slice if GLib >= 2.10;
                      ;  frees individual slices.
  ./epan/tvbuff.c     ; uses g_slice if GLib >= 2.10;
                      ;  frees individual slices.
  ./file.c            ; use GSlice if GLib >= 2.10;
                      ; frees via g_slice_free_chain