GNOME Bugzilla – Bug 330748
deadlock in base audio sink on playing->paused state change
Last modified: 2006-03-17 17:49:08 UTC
Occasionally I experience deadlocks in rhythmbox when changing songs. All rhythmbox is doing is calling gst_element_set_state (playbin, GST_STATE_READY). This is with fairly recent (~2 days) CVS checkouts. It doesn't seem to happen on a different machine running core 0.10.3, -plugins-base 0.10.2. [Switching to thread 5 (Thread -1276630096 (LWP 7241))]#0 0xffffe410 in __kernel_vsyscall () (gdb) where
+ Trace 66083
My vague guess as to what's happened: - thread 5 waits for a new segment from the ring buffer - thread 1 calls set_state, baseaudiosink calls ring_buffer_pause, then goes into base sink's change state function which blocks on the preroll lock (held by thread 5) - thread 2 calls ring_buffer_prepare_read, which returns FALSE because the ring buffer is paused, and goes on to wait on the audio ring buffer condition variable so, now thread 2 will never advance the ring buffer, so the thread 5 will never be unblocked, so the thread 1 will never get the preroll lock, and the state change will never return.
CC'ing Wim for comment
-core 0.10.3 and -base 0.10.2 can cause random audiosink delays and lockups when doing state changes. Can you test with -base 0.10.3 against -core 0.10.3?
I've upgraded to CVS HEAD for core and -base, and I've been testing it for a while. I was just about to close this bug when it happened again, with almost exactly the same stack traces.
ok, found how it could happen, _pause does not signal so the thread stays blocked in wait_segment, not knowing about the state change. patch comming up soon...
Can you retest with current -base CVS version?
I'm testing current -base CVS at the moment. Since I don't have a reliable way of triggering the bug, I'll wait a couple of days before closing the bug.
*** Bug 331225 has been marked as a duplicate of this bug. ***
I haven't seen it since, so I'm pretty confident it's fixed.
Or not. It's still happening, with the same stack traces for the three deadlocked threads.
*** Bug 326086 has been marked as a duplicate of this bug. ***
*** Bug 332214 has been marked as a duplicate of this bug. ***
can only sanely do this if #326311 is fixed
Created attachment 61453 [details] [review] don't start playback when we pause Added new method to enable/disable automatic start of the ringbuffer. This solves the race of the ringbuffer starting because it is filled and a state change function performing a _pause().
* gst-libs/gst/audio/gstbaseaudiosink.c: (gst_base_audio_sink_change_state): * gst-libs/gst/audio/gstringbuffer.c: (wait_segment), (gst_ring_buffer_may_start): * gst-libs/gst/audio/gstringbuffer.h: Only start playback if we are playing. should fix #330748.