[Bug 736071] New: Pulsesink Deadlock in gst_pulsesink_get_time

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=736071
  GStreamer | gst-plugins-good | 1.2.1

           Summary: Pulsesink Deadlock in gst_pulsesink_get_time
    Classification: Platform
           Product: GStreamer
           Version: 1.2.1
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: aksg86 at gmail.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


At times while doing the Pipeline state transition from PAUSED to PLAYING i see
a deadlock between the PulseAudio Main Loop thread and AudioBaseSink Render
thread. 

The PA thread holds the pulseaudio mainloop lock and is trying 
to obtain the pulsesink element lock in a call to
gst_element_post_message_default(). 

The AudioBaseSink render thread holds the pulsesink element lock and is trying
to obtain the pulseaudio mainloop lock in a call to gst_pulsesink_get_time(). 

Stack-trace of the 2 threads: 

Thread 1
#0 __lll_lock_wait (futex=0xe8a08, private=0) at
../ports/sysdeps/unix/sysv/linux/arm/nptl/lowlevellock.c:49
#1 0x40f725d0 in __pthread_mutex_lock (mutex=0xe8a08) at
pthread_mutex_lock.c:101
#2 0x410647f4 in g_mutex_lock (mutex=<optimized out>) at gthread-posix.c:208
#3 0x4074bfdc in gst_element_post_message_default (element=0xe9800,
message=0x51460) at gstelement.c:1677
#4 0x4074f668 in gst_element_post_message (element=0xe9800, message=0x51460) at
gstelement.c:1728
#5 0x41e77cf0 in mainloop_enter_defer_cb (api=<optimized out>,
userdata=0xe9800) at pulsesink.c:1135
#6 0x4089bfb8 in once_callback (m=0xede44, e=0x1739e0, userdata=<optimized
out>) at pulse/mainloop-api.c:47
#7 0x4089f0d0 in dispatch_defer (m=0xede00) at pulse/mainloop.c:682
#8 pa_mainloop_dispatch (m=0xede00) at pulse/mainloop.c:895
#9 0x4089f488 in pa_mainloop_iterate (m=0xede00, block=<optimized out>,
retval=0x0) at pulse/mainloop.c:935
#10 0x4089f544 in pa_mainloop_run (m=0xede00, retval=0x0) at
pulse/mainloop.c:950
#11 0x408ae518 in thread (userdata=0xea1a8) at pulse/thread-mainloop.c:88
#12 0x41415b5c in internal_thread_func (userdata=0xed388) at
pulsecore/thread-posix.c:83
#13 0x40f6fb3c in start_thread (arg=0x43011460) at pthread_create.c:306
#14 0x412f0868 in clone () from /rfs/lib/libc.so.6


Thread 2
#0 __pthread_mutex_lock_full (mutex=0xedeb0) at pthread_mutex_lock.c:303
#1 0x41414a48 in pa_mutex_lock (m=<optimized out>) at
pulsecore/mutex-posix.c:90
#2 0x41e7489c in gst_pulsesink_get_time (clock=<optimized out>, sink=<optimized
out>) at pulsesink.c:1935
#3 0x4272e2dc in gst_audio_clock_get_time (clock=<optimized out>) at
gstaudioclock.c:228
#4 0x4274692c in gst_audio_base_sink_sync_latency (obj=0x12eca8, bsink=0xe9800)
at gstaudiobasesink.c:1448
#5 gst_audio_base_sink_render (bsink=0xe9800, buf=0x12eca8) at
gstaudiobasesink.c:1628


Possible fix (maybe):

In gst_audio_base_sink_skew_slaving inside
gst-plugins-base/gst-libs/gst/audio/gstaudiobasesink.c we call
gst_audio_clock_get_time on sink->provided_clock without acquiring the
GST_OBJECT_LOCK(sink). Likewise in gst_audio_base_sink_setcaps. Can we do the
same in this case also?

Something like in the attached patch.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.