[Bug 760575] New: adaptivedemux: tests: possible deadlock on seek tests

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 760575
           Summary: adaptivedemux: tests: possible deadlock on seek tests
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: florin.apostol at oregan.net
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

While investigating another deadlock on seek tests I found the following one:

gst_adaptive_demux_test_run wants to move the pipeline from PAUSED to PLAYING.
For this it will register an idle task start_pipeline_playing and will call
g_main_loop_run. g_main_loop_run will call start_pipeline_playing which will
start to move all elements from the pipeline bin to playing. The first element
is httpsrc providing the manifest, the second element is the adaptive demux.

Immediately after being moved to playing, the http src will start providing a
manifest to adaptive demux. Despite being in paused state, adaptive demux will
process this manifest, create src pad, setup streams and start downloading
data.

For the seek tests, on one of the streaming tasks the test will create another
task to perform the seek. The streaming task will block until it sees the bin
containing the httpsrc element changing state from PLAYING to PAUSED.

The seek task will get a lock on adaptive demux and start the seek process.
Once the seek task has manged to change state on the bin containing the http
src element, a function registered to listen for state change messages will set
a flag to unblock the streaming task. This will allow the seek task to finish
changing state on httpsrc element and everything is fine.

The problem is that the function listening for state changes for the bin
containing the http src will also run on the main loop. Now, remember that
start_pipeline_playing only manged to change state for httpsrc and everything
started to roll. It also wants to change the state for adaptivedemux and this
will need to get the API lock in adaptivedemux. If the seek task got a chance
to run, it will grab and hold the API lock. Main loop will not be able to
finish the start_pipeline_playing so it will not be able to run the function
listening for state change on the bin containing http src. The whole system
deadlocks.

In practice, start_pipeline_playing will get the chance to also change state
for adaptivedemux element before the test gets as far as starting the seek
task. But while using the debugger to debug another problem and I blocked the
start_pipeline_playing before changing state for adaptive demux, the system
deadlocked.

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