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 699794 - uridecodebin: Leaking queue2 elements in playbin gapless mode
uridecodebin: Leaking queue2 elements in playbin gapless mode
Status: VERIFIED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
1.0.6
Other Linux
: Normal major
: 1.0.8
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2013-05-07 02:15 UTC by Henner Z.
Modified: 2013-05-09 16:30 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Test program to reproduce. (4.10 KB, text/x-csrc)
2013-05-07 02:15 UTC, Henner Z.
Details
Backtrace of about 40 threads being stuck. (46.96 KB, text/plain)
2013-05-08 05:47 UTC, Henner Z.
Details

Description Henner Z. 2013-05-07 02:15:19 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 )
Comment 1 Sebastian Dröge (slomo) 2013-05-07 08:54:22 UTC
Can you get a backtrace of all threads with gdb (threads apply all bt) after a few have accumulated already?
Comment 2 Henner Z. 2013-05-08 05:45:39 UTC
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:

Thread 133 (Thread 0x7fff5a7fc700 (LWP 14775))

  • #0 pthread_cond_wait
    at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S line 162
  • #1 g_cond_wait
    at /build/buildd/glib2.0-2.32.3/./glib/gthread-posix.c line 746
  • #2 gst_queue2_loop
    at gstqueue2.c line 2533
  • #3 gst_task_func
    at gsttask.c line 316
  • #4 g_thread_pool_thread_proxy
    at /build/buildd/glib2.0-2.32.3/./glib/gthreadpool.c line 309
  • #5 g_thread_proxy
    at /build/buildd/glib2.0-2.32.3/./glib/gthread.c line 801
  • #6 start_thread
    at pthread_create.c line 308
  • #7 clone
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S line 112
  • #8 ??

See full log attached as thread-log.txt
Comment 3 Henner Z. 2013-05-08 05:47:12 UTC
Created attachment 243560 [details]
Backtrace of about 40 threads being stuck.
Comment 4 Sebastian Dröge (slomo) 2013-05-08 12:55:06 UTC
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
Comment 5 Henner Z. 2013-05-09 16:30:58 UTC
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)