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 661738 - Deadlock between threads in gstaudiosink and gstringbuffer
Deadlock between threads in gstaudiosink and gstringbuffer
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
git master
Other All
: Normal critical
: 0.10.36
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-10-14 08:08 UTC by mersad
Modified: 2011-10-28 12:10 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description mersad 2011-10-14 08:08:30 UTC
When playing (continuously playing over and over again) audio using alsasink, the thread audioringbuffer_thread_func() in gstaudiosink.c stops at GST_AUDIORING_BUFFER_WAIT (buf) and in gstringbuffer.c in function wait_segment() (called by default_commit()) it stops at GST_RING_BUFFER_WAIT (buf). Just before GST_AUDIORING_BUFFER_WAIT (buf) the wait_segment() has already put the buffer to state PLAYING by calling gst_ring_buffer_start (buf) and we need to check this before calling GST_AUDIORING_BUFFER_WAIT (buf).

Suggestion to a solution under the else-statement in audioringbuffer_thread_func():

+      if (G_UNLIKELY (g_atomic_int_get (&buf->state) ==
+          GST_RING_BUFFER_STATE_STARTED)) {
+        GST_OBJECT_UNLOCK (abuf);
+        continue;
+      }
       GST_DEBUG_OBJECT (sink, "signal wait");
       GST_AUDIORING_BUFFER_SIGNAL (buf);
       GST_DEBUG_OBJECT (sink, "wait for action");
       GST_AUDIORING_BUFFER_WAIT (buf);
Comment 1 Mark Nauwelaerts 2011-10-28 12:10:43 UTC
Thanks, committed:

commit d430eb65c5e146681a5a1ff010d41c0fe7f55d67
Author: Mersad Jelacic <mersad@axis.com>
Date:   Fri Oct 28 13:58:47 2011 +0200

    audiosink: avoid deadlocking audioringbuffer thread
    
    ... when it goes into wait for ringbuffer starting just after such
    having been signalled.
    
    Fixes #661738.