GNOME Bugzilla – Bug 765906
typefind: Regression due to fix for 763491
Last modified: 2016-05-11 13:42:15 UTC
Created attachment 327154 [details] Pipeline The deadlock happens already at a very early step, that's why the pipeline dump is so simple. +++ This bug was initially created as a clone of Bug #763491 +++
Created attachment 327155 [details] GST_DEBUG="*:5"
Can you provide a testcase for reproducing the problem too?
The used media file can be found at https://github.com/youtube/js_mse_eme/blob/master/media/car_20130125_18.mp4.
Created attachment 327156 [details] Threads Backtrace (In reply to Sebastian Dröge (slomo) from comment #2) > Can you provide a testcase for reproducing the problem too? I'm trying, but as a first step I thought it could be useful to provide some more information.
So one thread (thread 1) is deactivating the typefind pad from PULL mode due to a state change (why is thread 1 doing that? is it shutting down the pipeline or is that still the state change of starting it?), while the other thread (typefind's task) is sending sticky events on that pad. For some reason it looks like there is a lock order problem or so, both threads seem to wait on a different stream lock: one is locking from srcpad to sinkpad (thread 1), the other from sinkpad to srcpad (the other thread that pushes events).
A testcase for this would definitely be helpful, it's not clear to me what this application is actually doing.
Created attachment 327236 [details] Desktop threads backtrace I bumped GStreamer versions to 1.8.1 in WebKitGTK+ and manage to reproduce what I think is the same problem. I'm attaching the backtraces.
Created attachment 327237 [details] [review] Bump WebKitGTK+ dependencies to 1.8.1 To ease the the process of bumping the GStreamer versions at WebKitGTK+ though you'd probably like to have your own repos instead :)
I must say that at my desktop it was no easy to get it blocked there.
(In reply to Sebastian Dröge (slomo) from comment #6) > A testcase for this would definitely be helpful, it's not clear to me what > this application is actually doing. As you could see in my last comments I tried to reproduce the bug in WKGTK+ to see if you can get some interesting info from it. I'll continue to try to produce a test case with an appsrc feeding info a playbin.
I like WTF::ParkingLot ;) Looks indeed like the same problem. type found sends out the sticky events from the src pad and blocks on the stream lock of the next sink pad, all this happening from the task function on the sinkpad (i.e. the sinkpad stream lock is taken of typefind and the one of the next downstream element is trying to be taken but deadlocks). At the same time the main thread shuts down the pipeline, which then deadlocks on the sinkpad stream lock of typefind, supposedly because the next downstream sinkpad stream lock is already taken. In thread 1, gst_qtdemux_change_state() (frame 14) deactivates the pads of typefind (frame 4). So basically we have upstream stream lock -> downstream stream lock vs. the other way around here. And this happens because of the PULL mode special case (sinkpad of qtdemux), which directly deactivates the peer srcpad. I assume the problem here is that typefind was pulling itself (that's why the task is running at all), then it was emitting type-found from there, then qtdemux was plugged, was activating in pull mode itself and deactivating typefind from pull mode. typefind should've shut down the task though but doesn't, it only pauses the task because otherwise we would deadlock (we would shut down the task from itself). Then the pipeline is shut down while the task is still running, so qtdemux deactivates from pull mode which then again pauses the task. Not sure what to do about this. Maybe we just have to detect this case in typefind where it is actually not running in pull mode anymore so won't have to shut down the task anymore here (although it is still running and would just disappear on the next opportunity).
Note that this is unrelated to the actual fix for bug #763491 but a general problem that should've existed before already.
A non-streamlock protected boolean that remembers the (target) task state might be an option btw
Created attachment 327639 [details] [review] typefind: Only push a CAPS event downstream if the sinkpad is not in PULL mode The other signal handlers of the type-found signal might have reactivated typefind in PULL mode already, pushing a CAPS event at that point would cause deadlocks and is in general unexpected by elements that are in PULL mode.
It works. \o/
Attachment 327639 [details] pushed as 5e43ee5 - typefind: Only push a CAPS event downstream if the sinkpad is not in PULL mode
Will backport to 1.8.2 in a bit