Created attachment 24557 [details]
program to demonstrate the leak

More details: 
 
No leak: 
  * mpeg/audio files without any ID3 tags 
  * mpeg/audio files with only an ID3v1 tag at the end 
 
Leak: 
  * mpeg/audio files with only an ID3v2.3.0 tag at the beginning of 
the file  
 
Cheers 
-Tim 
 
 

rhythmbox consumes huge amount of memory (mine went up to 600
megabytes) when using gstreamer to read metadatas, this is probably
related to that bug.

I think this was fixed:

2004-03-06  Benjamin Otte  <otte@gnome.org>

        * ext/mad/gstid3tag.c: (gst_id3_tag_chain):
          fix huge leak: gst_buffer_merge doesn't unref the first argument
          itself.

I don't think this is fully fixed yet. 
 
As far as I can see, it leaks less than before, but still leaks 
massively, with CVS HEAD from 2004-March-09. 
 
 
 

Some more information: 
 
I think the 'mad' element that is created when running the  
 
        filesrc ! typefind ! spider ! fakesink 
 
pipeline on an mp3 file is never disposed of when the pipeline gets 
destroyed. 
 
Here's what I did to come to that conclusion: 
 
static gpointer maddata;  /* NULL */ 
static gpointer pipedata; /* NULL */ 
 
static void 
ea_cb (GstBin *spider, GstElement *element, gpointer foo) 
{ 
  g_print("ELEMENT ADDED: %s\n", gst_element_get_name(element)); 
  if (strncmp(gst_element_get_name(element), "mad", 3) == 0) 
  { 
    g_print ("hooking up nullifier...\n"); 
    maddata = spider; 
    g_object_set_data_full(G_OBJECT(element), "madfoo", &maddata, 
(GDestroyNotify)g_nullify_pointer); 
  } 
} 
 
..... 
 
g_signal_connect(spider, "element-added", ea_cb, NULL); 
 
gobject_set_data_full(G_OBJECT(pipeline), "pipefoo", &pipedata, 
(GDestroyNotify)g_nullify_pointer); 
 
...... 
 
after the pipeline is unrefed, pipedata will be NULL, but maddata 
will still be some non-NULL value, so the mad object didn't get 
destroyed. 
 
I am not sure if that would cause huge leaks like that, but it's 
worth a shot. 
 
Hope this helps whoever is debugging this further :) 
 
Cheers 
-Tim 
 

The pipeline

  filesrc ! typefind ! spider ! fakesink

doesn't create a mad element.

I meant: if you feed it an mp3 file as input... 
 
 

same thing.  You have to use a pipeline like the following to get a
mad element:

  filesrc ! typefind ! spider ! audio/x-raw-int ! fakesink

gah - yes, of course. It wasn't meant as an exact gst-launch 
pipeline but refered to the above attached test program, which in 
fact does exactly that. And _obviously_ it must have created a a mad 
element somewhere, because otherwise my callback wouldn't have 
worked, would it? 
 
Anyway, this discussion doesn't add any useful info at all, so maybe 
we can stop it. 
 

Maybe this has something to do with it? (This is after the pipeline has been 
unref'ed) 
 
Patch attached (doesn't fix the problem though, just a small part of it). 
 
 2380428 bytes in 16219 blocks are still reachable in loss record 23 of 23 
    at 0x3C01FD01: realloc (vg_replace_malloc.c:162) 
    by 0x3C31C870: g_realloc (gmem.c:169) 
    by 0x3C2FF4FA: g_array_maybe_expand (garray.c:350) 
    by 0x3C2FED8B: g_array_append_vals (garray.c:138) 
    by 0x3C07F228: gst_structure_set_field (gststructure.c:450) 
    by 0x3C07ED66: gst_structure_id_set_value (gststructure.c:288) 
    by 0x3C054F45: gst_caps_structure_intersect_field (gstcaps.c:713) 
    by 0x3C07F9C9: gst_structure_foreach (gststructure.c:722) 
    by 0x3C054FBF: gst_caps_structure_intersect (gstcaps.c:741) 
    by 0x3C05517D: gst_caps_intersect (gstcaps.c:840) 
    by 0x3C90A028: gst_autoplug_caps_intersect (gstsearchfuncs.c:64) 
    by 0x3C90A13B: gst_autoplug_can_connect_sink (gstsearchfuncs.c:132) 
    by 0x3C90A741: gst_autoplug_sp (gstsearchfuncs.c:349) 
    by 0x3C9080F0: gst_spider_plug_from_srcpad (gstspider.c:690) 
    by 0x3C907E79: gst_spider_plug (gstspider.c:656) 
    by 0x3C907637: gst_spider_identity_plug (gstspider.c:499) 
    by 0x3C909D59: gst_spider_identity_sink_loop_type_finding 
(gstspideridentity.c:569) 
    by 0x3C8DAAAA: loop_group_schedule_function (gstoptimalscheduler.c:1166) 
    by 0x3C8DA4A1: schedule_group (gstoptimalscheduler.c:1009) 
    by 0x3C8DA565: gst_opt_scheduler_schedule_run_queue 
(gstoptimalscheduler.c:1052) 
 
 
Cheers 
 -Tim 
 

Created attachment 26234 [details] [review]
proposed patch: free structure->fields GArray in gst_structure_free()

I tested this patch with Rhythmbox library import, and it reduces memory leaks
by 25% ;)
Without the patch, after importing 1500 files (using gstreamer to read
metadata), rhythmbox uses 102MB. With the patch, it "only" eats 78MB

patch applied, leaving open as it isn't fixed completely.

I believe this is fixed after the recent memleak fixage.