GNOME Bugzilla – Bug 690605
Rhythmbox, Totem, Clementine, etc. freeze when trying to stop/pause/play songs
Last modified: 2013-08-16 10:11:25 UTC
Created attachment 232046 [details] A full backtrace of this deadlock (RB and GST 1.0.4) Hello, Firstly, thank you for developing GStreamer and all other things! :) I'm using Ubuntu Raring 13.04 with GStreamer 1.0.4 and 0.10.36 and GLib 2.34.3. It seems that a few apps which use GStreamer 1.0 (Rhythmbox, Totem) and 0.10 (Clementine) freeze when trying to stop/pause/play next/play songs. It's not hard to reproduce this bug on Ubuntu Raring 13.04 (e.g. by using Daily-LiveCD: http://cdimage.ubuntu.com/daily-live/current/). This bug has already been reported on Launchpad: https://bugs.launchpad.net/bugs/1092231 . It seems it's not linked to the bug 670846 because I'm using a newer version of GLib which includes this patch. I hope it will help you to fix this bug :)
According to the backtrace produced with RB, it seems it crashes in gst_pad_pause_task () => http://cgit.freedesktop.org/gstreamer/gstreamer/tree/gst/gstpad.c#n5261 ------ /* wait for task function to finish, this lock is recursive so it does nothing * when the pause is called from the task itself */ => GST_PAD_STREAM_LOCK (pad); GST_PAD_STREAM_UNLOCK (pad); return res; ------ About GST_PAD_STREAM_LOCK: ------ #define GST_PAD_STREAM_LOCK(pad) g_rec_mutex_lock(GST_PAD_GET_STREAM_LOCK(pad)) ------ I don't know what 'recursive' means here but it's just a simple pthread_mutex_lock (): http://git.gnome.org/browse/glib/tree/glib/gthread-posix.c#n363 ------ g_rec_mutex_lock (GRecMutex *mutex) { pthread_mutex_lock (g_rec_mutex_get_impl (mutex)); } ------ It's not like this deprecated function: g_static_rec_mutex_(un)lock_full () which completely (un)locks the mutex: http://git.gnome.org/browse/glib/tree/glib/deprecated/gthread-deprecated.c#n769
Created attachment 232048 [details] A full backtrace of this crash (Clementine and GST 0.10.36)
Created attachment 232049 [details] A full backtrace of this crash (Clementine and GST 0.10.36 without GST-PulseAudio plugin)
Let's ignore 0.10 stuff. I will try and reproduce with the latest rhythmbox. I'm using totem with 1.0 (git master) all the time and haven't run into this yet. How do you reproduce it? Just load a bunch of music files and hit the next button as soon as they start playing?
Thank you for this quick answer! > I'm using totem with 1.0 (git master) all the time and haven't run into this yet. It was not easy to reproduce it with Totem but I was able to reproduce it after ~2min of stress tests (play/pause/next) > How do you reproduce it? Just load a bunch of music files and hit the next button as soon as they start playing? Yes but it seems it's easier to reproduce it by only hitting play/pause button quickly or not. Note that it's easier to reproduce it by using keyboard shortkeys (to hit play/pause/next quickly) and gdb to slow down the application. > Let's ignore 0.10 stuff. Ok but it's strange to have this bug with 0.10 too, no?
I can reproduce some issues with rhythmbox git master and GStreamer git master. I've seen a crash like this: (lt-rhythmbox:3589): GStreamer-CRITICAL **: gst_buffer_map_range: assertion `GST_IS_BUFFER (buffer)' failed Segmentation fault (Haven't seen that in gdb yet) And I just got a deadlock (UI freeze) like this: ^C Program received signal SIGINT, Interrupt. __lll_lock_wait () at ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S:136 136 ../nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.S: No such file or directory. (gdb) thread apply all bt
+ Trace 231315
Thread 41 (Thread 0x7fffc73cf700 (LWP 3754))
Thread 1 (Thread 0x7ffff7f979c0 (LWP 3710))
Is this still a problem with latest git master? I fixed similar looking problems some time ago
Probably a duplicate of #700342 *** This bug has been marked as a duplicate of bug 700342 ***
Yes I forgot to update the status because this bug seems to be fixed now, thank you :-)