[Bug 766064] New: basesink: deadlock waiting prerolling while pipeline goes to NULL state

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=766064

            Bug ID: 766064
           Summary: basesink: deadlock waiting prerolling while pipeline
                    goes to NULL state
    Classification: Platform
           Product: GStreamer
           Version: 1.8.2
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: mparisdiaz at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Hello,
there is a deadlock when a pipeline goes to NULL state and BaseSink is waiting
for prerolling.

There are 2 threads:
 streaming_thread: managed by the task of the SrcPad of a BaseSrc (in our case
a NiceSrc)
 app_thread: performs the state change of the pipeline to NULL
(gst_element_set_state (pipeline, GST_STATE_NULL);)

The deadlock takes places with this race condition:
  1 - [app_thread] when the pipeline is going to NULL the BaseSink (in our case
a FakeSink) is an state which it needs to do prerolling (see
[gdb-fakesink_state.txt] where you can see the state)
  2 - [streaming_thread] A buffer arrives to the BaseSink
    2.1 - This causes preroll_wait [1] (see [gdb-wait_preroll.txt])
    2.2 - Here, the streaming_thread is blocked and so all upstream pads [2]
  3- [app_thread] tries to change the state of one of the pads blocked in step
(2)
    3.1 - it is blocked in [3] why the mutex is locked by [streaming_thread]
(ver [gdb-activate_mode_internal.txt])

Refs
[1]https://github.com/Kurento/gstreamer/blob/0fb3a083ce04551fbdba7a94f0ac5612515bda67/libs/gst/base/gstbasesink.c#L2212
[2]
https://github.com/Kurento/gstreamer/blob/0fb3a083ce04551fbdba7a94f0ac5612515bda67/gst/gstpad.c#L4125
[3]
https://github.com/Kurento/gstreamer/blob/0fb3a083ce04551fbdba7a94f0ac5612515bda67/gst/gstpad.c#L1012

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.