GNOME Bugzilla – Bug 699794
uridecodebin: Leaking queue2 elements in playbin gapless mode
Last modified: 2013-05-09 16:30:58 UTC
Created attachment 243449 [details] Test program to reproduce. Affects 1.0 but as well seen in 0.10 With each stream played over the network (here: sounds via HTTP), a thread is leaked. Probably some thread created for streaming/buffering that never is cleaned up after the stream has stopped playing. In the attached example, I play a URL over and over; whenever end of stream is reached (in bus message GST_MESSAGE_EOS), the URL is re-played via a GST_STATE_READY, set-uri, GST_STATE_PLAYING sequence. With standard Linux tools, we can see that the number of threads increase by one for every repetition played, without ever getting cleaned up: while : ; do ps -eLf | grep ./test-loop | grep -v grep | wc -l ; sleep 1 ; done Eventually, this ties up so many threads, that things stop working (as happening for the project I am working on that uses gstreamer: gmrender-resurrect )
Can you get a backtrace of all threads with gdb (threads apply all bt) after a few have accumulated already?
Run with the -dbg libraries found in <http://ppa.launchpad.net/gstreamer-developers/ppa/ubuntu>. Stopped the threads after about 40 repetitions. All leaked threads look like this:
+ Trace 231911
Thread 133 (Thread 0x7fff5a7fc700 (LWP 14775))
See full log attached as thread-log.txt
Created attachment 243560 [details] Backtrace of about 40 threads being stuck.
This should fix it, please test. commit 4c52518ef55fded81dd75178c90175d212762ef7 Author: Sebastian Dröge <sebastian.droege@collabora.co.uk> Date: Wed May 8 14:52:18 2013 +0200 uridecodebin: Always store queue2 elements for later removal Otherwise we accumulate more and more queue2 elements, and let each of them start a thread doing nothing but waiting each time uridecodebin goes to PAUSED. https://bugzilla.gnome.org/show_bug.cgi?id=699794
Confirmed that fix is working. Compiled from git with and without your change. Without the change, I observe the leak, with the change: fixed. Thanks! (Given that this is a very trivial fix, could you fix this as well in the 0.10 branch ? I know that it is not supported anymore, but I assume that the code is very similar there, and I have seen still many distributions packaging 0.10)