[Bug 760575] New: adaptivedemux: tests: possible deadlock on seek tests
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Wed Jan 13 04:51:40 PST 2016
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.
More information about the gstreamer-bugs
mailing list