After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 446759 - missing caps unref inside typefind element
missing caps unref inside typefind element
Status: RESOLVED DUPLICATE of bug 475451
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2007-06-12 14:37 UTC by Laurent Glayal
Modified: 2007-09-11 09:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
add gst_caps_unref() in dispose() funct. (760 bytes, patch)
2007-06-12 14:38 UTC, Laurent Glayal
rejected Details | Review

Description Laurent Glayal 2007-06-12 14:37:46 UTC
Adding gst_cap_unref() in order to avoid memleak.
Regards
Comment 1 Laurent Glayal 2007-06-12 14:38:24 UTC
Created attachment 89811 [details] [review]
add gst_caps_unref() in dispose() funct.
Comment 2 Tim-Philipp Müller 2007-06-12 15:29:24 UTC
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?
Comment 3 Laurent Glayal 2007-06-12 16:08:56 UTC
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. 
Comment 4 Stefan Sauer (gstreamer, gtkdoc dev) 2007-09-10 08:11:59 UTC
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)
Comment 5 Tim-Philipp Müller 2007-09-10 10:24:53 UTC
Stefan: this leak is not the same as the one in bug #474880 then?
Comment 6 Stefan Sauer (gstreamer, gtkdoc dev) 2007-09-10 11:45:24 UTC
No, its something else.
Comment 7 Stefan Sauer (gstreamer, gtkdoc dev) 2007-09-11 06:00:22 UTC
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.
Comment 8 Tim-Philipp Müller 2007-09-11 09:47:59 UTC
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 ***
Comment 9 Laurent Glayal 2007-09-11 09:55:02 UTC
Ok. Thank you.