GNOME Bugzilla – Bug 583255
[playbin2] deadlock when disabling visualisations
Last modified: 2009-11-02 18:29:06 UTC
Observed this deadlock with totem and playbin2 earlier, while it was resetting at the end of a file:
+ Trace 215610
Thread 1 (Thread 0xb8034770 (LWP 30539))
Very similar looking deadlock from today (not sure what triggered it, was in the middle of a sing; possible I clicked on the 'enable visualisation' checkbox while it was playing without vis enabled, or changing vis, don't remember exactly:
+ Trace 215755
Thread 1 (Thread 0x7fcf5a4a9810 (LWP 6892))
Just got exactly the same deadlock when disabling visualisations while playing a file (file attached to bug #591165). (gdb) t a a bt
+ Trace 216849
Thread 1 (Thread 0x7fdfafba97d0 (LWP 8851))
*** Bug 591595 has been marked as a duplicate of this bug. ***
Created attachment 143243 [details] gdb trace made per Ubuntu's guidelines Here's another stack trace for the disabling-visualization while playing audio crash. [ Filed here from https://bugs.launchpad.net/ubuntu/+source/gstreamer0.10/+bug/428987 where a user said this would be an upstream issue ]
This also happens regularly when changing tracks, not only when enabling/disabling visualisations (there might be another report about that, but I can't find it right now). Marking as blocker, since I think we should really fix this before the release if possible at all.
*** Bug 595285 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > This also happens regularly when changing tracks, not only when > enabling/disabling visualisations (there might be another report about that, > but I can't find it right now). Bug #595285 is such a bug, though it doesn't have such a useful trace.
ping? It's been a week - is anyone looking at this bug?
I don't know how to fix this bug. Basically, we need playsink not to hold the PLAY_SINK_LOCK while doing operations on the video/audio chains, such as change their state or adding/removing them from the bin. One way would be to protect those 'sensitive' operations with a different lock.
Created attachment 144196 [details] [review] possible patch Make the lock recursive for now.
Making the lock recursive doesn't actually help in the larger scheme - it just exposes a different deadlock in Totem:
+ Trace 217934
Thread 4 (Thread 0xb35ffb90 (LWP 8280))
Alright, punting this in favour of making the releases. It is annoying, but it isn't a regression, and we clearly need more time to figure out how to fix it.
(In reply to comment #12) > Alright, punting this in favour of making the releases. It is annoying, but it > isn't a regression, and we clearly need more time to figure out how to fix it. But it causes a regression in Totem...
Switching to playbin2 prematurely causes a regression in Totem :-P OK - let's apply the hacky fix. The secondary lockup can be worked around in Totem: diff --git a/src/backend/bacon-video-widget-gst-0.10.c b/src/backend/bacon-video-widget-gst-0.10.c index 5500d99..e963d46 100644 --- a/src/backend/bacon-video-widget-gst-0.10.c +++ b/src/backend/bacon-video-widget-gst-0.10.c @@ -5950,6 +5950,7 @@ bvw_update_interface_implementations (BaconVideoWidget *bvw) GstElement *video_sink = NULL; GstElement *element = NULL; GstIterator *iter; + GstElement *play; if (g_thread_self() != gui_thread) { if (bvw->priv->balance) @@ -5969,8 +5970,14 @@ bvw_update_interface_implementations (BaconVideoWidget *bvw) return; } + play = gst_object_ref(bvw->priv->play); + + g_mutex_unlock (bvw->priv->lock); g_object_get (bvw->priv->play, "video-sink", &video_sink, NULL); g_assert (video_sink != NULL); + g_mutex_lock (bvw->priv->lock); + + gst_object_unref(play); /* We try to get an element supporting XOverlay interface */ if (GST_IS_BIN (video_sink)) {
commit a8d7e6a4901a21ebb4d1e0937e6be7309e8146ac Author: Wim Taymans <wim.taymans@collabora.co.uk> Date: Mon Sep 28 22:06:11 2009 +0200 playsink: make the lock recursive for now Fixes #583255
*** Bug 600459 has been marked as a duplicate of this bug. ***