GNOME Bugzilla – Bug 774854
queue(2): validate: Deadlock when seeking on a dash stream
Last modified: 2016-12-13 19:42:44 UTC
Validate test: validate.dash.playback.seek_with_stop.dash_exMPD_BIP_TC1 Failure example: https://ci.gstreamer.net/job/GStreamer-master-meson-validate/lastCompletedBuild/testReport/validate.dash.playback/seek_with_stop/dash_exMPD_BIP_TC1/ Stack trace (from above link):
+ Trace 236877
Thread 10 (Thread 0x7f6e8e7fc700 (LWP 7966))
Thread 9 (Thread 0x7f6e8effd700 (LWP 7965))
Thread 8 (Thread 0x7f6e8ffff700 (LWP 7963))
Thread 7 (Thread 0x7f6ea9af3700 (LWP 7960))
Thread 6 (Thread 0x7f6eaa2f4700 (LWP 7959))
Thread 5 (Thread 0x7f6eab1c0700 (LWP 7958))
Thread 4 (Thread 0x7f6eabfff700 (LWP 7957))
Thread 3 (Thread 0x7f6eb3f23700 (LWP 7956))
Thread 1 (Thread 0x7f6ebb78c780 (LWP 7953))
Basically problem is as follow: * T1. Validate scenario is seeking -> dashdemux reset it the internal src bin (which contains a queue2) state to READY -> GstElement deactivate the queue2 src pad, bringing down the queue src pad task in gst_queue2_src_activate_push (From what I can say, right after the task is paused, we get to T3 action) -> GstElement deactivate the queue2 sink pad trying to get the sinkpad STREAM_LOCK * T3. Waiting for a ALLOCATION query to be processed but there is no srcpad thread anymore to process it
Created attachment 340549 [details] [review] queue2: Unblock any ongoing serialize query when shuting down In case we have a serialize query happening when going from PAUSED to READY after the srcpad task was stop and the moment we deactivate the sinkpad, we need to make sure we wake up the stuck sinkpad streaming thread to be able to get the sinkpad stream lock.
Working on a GstHarness test.
Comment on attachment 340549 [details] [review] queue2: Unblock any ongoing serialize query when shuting down Trying hard to reproduce the race I was understanding let me notic that this case is not possible because we properly set sinkresult to FLUSHING when deactivating the source pad.
Btw, this same issue happens with validate.dash.playback.seek_forward.dash_exMPD_BIP_TC1: https://ci.gstreamer.net/job/GStreamer-master-validate/4048/testReport/junit/validate.dash.playback/seek_forward/dash_exMPD_BIP_TC1/
Interestingly, a very similare issue seems to happen on queue itself: https://ci.gstreamer.net/job/GStreamer-master-validate/4053/testReport/junit/validate.http/media_check/vorbis_theora_1_ogg/ [New LWP 14823] [New LWP 14822] [New LWP 14821] [New LWP 14816] [New LWP 14814] [New LWP 14813] [New LWP 14810] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". 0x00007f6358d928ad in __lll_lock_wait () from /lib64/libpthread.so.0
+ Trace 236895
Thread 7 (Thread 0x7f6339c1d700 (LWP 14813))
Thread 6 (Thread 0x7f6339202700 (LWP 14814))
Thread 5 (Thread 0x7f6333fff700 (LWP 14816))
Thread 4 (Thread 0x7f63337fe700 (LWP 14821))
Thread 3 (Thread 0x7f6332ba3700 (LWP 14822))
Thread 2 (Thread 0x7f6331cbc700 (LWP 14823))
Thread 1 (Thread 0x7f635a807800 (LWP 14808))
And another occurrence of it in gstqueue: https://ci.gstreamer.net/job/GStreamer-master-validate/4177/testReport/junit/ges.playback.scrub_backward_seeking.test_mixing/audio_video/vorbis_vp8_webm/
*** This bug has been marked as a duplicate of bug 776039 ***