GNOME Bugzilla – Bug 760575
adaptivedemux: tests: possible deadlock on seek tests
Last modified: 2018-05-06 12:20:31 UTC
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.
I'm a bit confused by all this. Is this still a problem? Can you provide a back trace? Do you have any patches or ideas how to solve it? This is all non-live, so only sinks will care about PLAYING vs. PAUSED state, all other elements will behave the same. State changes will be done by the bins/pipeline from sink to source. The httpsrc will start producing data when it moves from READY to PAUSED state.
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!