GNOME Bugzilla – Bug 756552
playbin: Leaking sinks when repeating state changes from NULL->PLAYING in a loop
Last modified: 2015-10-15 06:42:33 UTC
Created attachment 313241 [details] C example code The attached examples leaks one GstAudioClock, GstPad, GstPulseSink per run.
If you just run it, it will also run out of file descriptors very soon. And give these assertions: (lt-tset:27882): GStreamer-CRITICAL **: gst_poll_get_read_gpollfd: assertion 'set != NULL' failed So somewhere we're leaking things :)
Not looking into this now btw, would be great if someone else could :)
f99a24f8b3ab1d0fa0cc56432b766a5c1ae85fb4 is the first bad commit commit f99a24f8b3ab1d0fa0cc56432b766a5c1ae85fb4 Author: Sebastian Dröge <sebastian@centricular.com> Date: Fri Jul 10 11:53:24 2015 +0300 playsink: Require the streamvolume interface on the sink when using the sink's volume/mute properties If the sink has properties named volume and mute, we have no idea about their meaning. The streamvolume interface standardizes the meaning. In the case of osxaudiosink for example, the current volume property has a range of 0.0 to 1.0, but we need 0.0 to 10.0 or similar. Also osxaudiosink has no mute property. As such, the volume element should be used here instead. https://bugzilla.gnome.org/show_bug.cgi?id=752156
Created attachment 313349 [details] [review] fix element leak As mentioned by Christoph Reiter, the issue seems to be happening because of commit f99a24f8b3ab1d0fa0cc56432b766a5c1ae85fb4 The problem here is previously elem = gst_play_sink_find_property_sinks (playsink, chain->sink, "volume", G_TYPE_DOUBLE); this is a transfer none function and need not be freed explicitly. After the change, we are using if (GST_IS_BIN (chain->sink)) elem = gst_bin_get_by_interface (GST_BIN_CAST (chain->sink), GST_TYPE_STREAM_VOLUME); else if (GST_IS_STREAM_VOLUME (chain->sink)) elem = gst_object_ref (chain->sink); else elem = NULL; where gst_bin_get_by_interface is also transfer FULL. So we are getting the reference of the volume element. And the same is being simply set to NULL before freeing. resulting in leaks. PS: hope i did not hijack this issue from Christoph :)
That's bug #755867 :) Let's continue discussing there and getting a good patch together. *** This bug has been marked as a duplicate of bug 755867 ***