Created attachment 89811 [details] [review]
add gst_caps_unref() in dispose() funct.

Not that it hurts to add the patch, but the caps should be freed in the READY => NULL state change as far as I can see, and I can't think of any scenarios where we save caps but not actually succeed to change state to READY, so do you know why the existing unref doesn't work in your case? Do you set the element state to NULL before you unref it/the pipeline?

The leak was observed inside a decodebin, i don't have any valgrind trace anymore, the decodebin was properly set to NULL state before removing it from pipeline. No  error/warning reported, just some leak. 

For me the patch makes no difference. I added some logging and the caps are cleared already during gst_type_find_element_change_state:

Setting pipeline to READY ...
0:00:40.280169000  7400 0x431c128 WARN              typefind gsttypefindelement.c:780:gst_type_find_element_change_state: paused->ready or ready->null 0x46875f8
Setting pipeline to NULL ...
0:00:40.299225000  7400 0x431c128 WARN              typefind gsttypefindelement.c:780:gst_type_find_element_change_state: paused->ready or ready->null 0x46875f8
FREEING pipeline ...
0:00:40.364913000  7400 0x431c128 WARN              typefind gsttypefindelement.c:266:gst_type_find_element_dispose: self 0x46875f8, store (nil), caps (nil)


This is from valgrind, duno if this is the same leak you are seeing.
59,991 (3,024 direct, 56,967 indirect) bytes in 252 blocks are definitely lost in loss record 4,082 of 4,089
==7187==    at 0x4021835: malloc (vg_replace_malloc.c:207)
==7187==    by 0x41592C5: g_malloc (gmem.c:131)
==7187==    by 0x4168E97: g_slice_alloc (gslice.c:777)
==7187==    by 0x4133E4A: g_ptr_array_sized_new (garray.c:372)
==7187==    by 0x4133E91: g_ptr_array_new (garray.c:366)
==7187==    by 0x4066C56: gst_static_caps_get (gstcaps.c:460)
==7187==    by 0x48386CC: analyze_new_pad (gstdecodebin2.c:1297)
==7187==    by 0x4839713: type_found (gstdecodebin2.c:1146)
==7187==    by 0x40B831C: gst_marshal_VOID__UINT_BOXED (gstmarshal.c:507)
==7187==    by 0x40E762A: g_closure_invoke (gclosure.c:490)
==7187==    by 0x40F8102: signal_emit_unlocked_R (gsignal.c:2440)
==7187==    by 0x40F9626: g_signal_emit_valist (gsignal.c:2199)
==7187==    by 0x40F97E8: g_signal_emit (gsignal.c:2243)
==7187==    by 0x489C80A: gst_type_find_element_activate (gsttypefindelement.c:748)
==7187==    by 0x408AB2B: gst_pad_set_active (gstpad.c:648)
==7187==    by 0x407143A: activate_pads (gstelement.c:2486)
==7187==    by 0x407E3C6: gst_iterator_fold (gstiterator.c:503)
==7187==    by 0x4070EB1: iterator_activate_fold_with_resync (gstelement.c:2518)
==7187==    by 0x4070F77: gst_element_pads_activate (gstelement.c:2561)
==7187==    by 0x40712E5: gst_element_change_state_func (gstelement.c:2626)
==7187==    by 0x489AAF7: gst_type_find_element_change_state (gsttypefindelement.c:775)
==7187==    by 0x406DB08: gst_element_change_state (gstelement.c:2402)
==7187==    by 0x406DF68: gst_element_set_state_func (gstelement.c:2352)
==7187==    by 0x406CB52: gst_element_set_state (gstelement.c:2258)
==7187==    by 0x4061024: gst_bin_change_state_func (gstbin.c:1920)
==7187==    by 0x483AF25: gst_decode_bin_change_state (gstdecodebin2.c:2182)
==7187==    by 0x406DB08: gst_element_change_state (gstelement.c:2402)
==7187==    by 0x406DF68: gst_element_set_state_func (gstelement.c:2352)
==7187==    by 0x406CB52: gst_element_set_state (gstelement.c:2258)
==7187==    by 0x4061024: gst_bin_change_state_func (gstbin.c:1920)
==7187==    by 0x408D9C6: gst_pipeline_change_state (gstpipeline.c:503)
==7187==    by 0x406DB08: gst_element_change_state (gstelement.c:2402)
==7187==    by 0x406D7B4: gst_element_continue_state (gstelement.c:2112)
==7187==    by 0x406DBE5: gst_element_change_state (gstelement.c:2439)
==7187==    by 0x406DF68: gst_element_set_state_func (gstelement.c:2352)
==7187==    by 0x406CB52: gst_element_set_state (gstelement.c:2258)
==7187==    by 0x804B1A2: main (gst-launch.c:757)

Stefan: this leak is not the same as the one in bug #474880 then?

No, its something else.

I have files my leak as Bug #475723 together with a patch. Together with the patch in Bug #475451 it makes decodebin leak-free for me.

Yay!  Let's close this one then, since there's not much info for us to go on in here anyway.  I wouldn't be surprised if there are other leaks, but if there are new bugs with info on how to reproduce them will surely be filed sooner or later.

Laurent: please re-open or file a new bug if you still get the leak with up-to-date core+base CVS after the two bugs mentioned by Stefan have been resolved. Thanks!


*** This bug has been marked as a duplicate of 475451 ***

Ok. Thank you.