After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 760575 - adaptivedemux: tests: possible deadlock on seek tests
adaptivedemux: tests: possible deadlock on seek tests
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-bad
git master
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-01-13 12:51 UTC by Florin Apostol
Modified: 2018-05-06 12:20 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Florin Apostol 2016-01-13 12:51:40 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.
Comment 1 Tim-Philipp Müller 2016-05-28 17:19:02 UTC
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.
Comment 2 Vivia Nikolaidou 2018-05-06 12:20:31 UTC
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!