[Bug 765906] typefind: Regression due to fix for 763491

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=765906

--- Comment #11 from Sebastian Dröge (slomo) <slomo at coaxion.net> ---
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).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.