GNOME Bugzilla – Bug 663701
videomixer: deadlock in stream lock
Last modified: 2014-06-22 13:45:02 UTC
Created attachment 201084 [details] Backtrace of deadlock One freeze detected using GES (gnonlin) testing with a simple media timeline layer with basic transitions with pattern - transition - pattern. There is a deadlock in on GST_COLLECT_PADS2_STREAM_LOCK in gst/videomixer/gstcollectpads2.c It does not happen 100%, but maybe 80% of the times. If GST_DEBUG log 5 is enabled then it happens less often, there is some race condition. Vincent take a looked and reported "So that seems to be the issue with that GES hang. gnlcomposition doesn't forward the flush start, and another thread is blocked in _chain; the log shows: gst_pad_push_event:<gnloperation6:src> Pad is blocked, not forwarding flush-start, doing block signal." We have just been able to reproduce with GES webkit demo. We tried to reproduce the problem with ges-launch without success, so it might be related with webkit sink. Note: Not sure what component to assign the bug to, feel free to properly reassign it. The backtrace shows gst-editing-services, gnonlin, gst-plugins-good (videomixer). And there is additionally the webkit sink which might interfere somehow. Attached can find a full backtrace of the problem for all threads. I hope it helps. STEPS TO REPRODUCE THE PROBLEM: 1) This has been tested with Ubuntu Oneiric + modified webkit for GES webkit demo, you can find those packages in: https://launchpad.net/~zdra/+archive/prague-demo Just install the witivi packages with its dependencies. 2) Run witivi, drag and drop two video source to the timeline and add a transition in the middle. 3) Play the timeline, close to the finish of the first clip (first video source), when the transition is beginning or about to begin, it freezes the whole application.
This doesn't look like a regression and as such is no blocker. The problem here really seems to be that the flush-start event is not properly forwarded, which results in the videomixer2 collected function not being unlocked. This then causes a deadlock because the collectpads2 streamlock is never released. The flush-start event should be forwarded by gnlcomposition and this looks like a bug in gnonlin or ges because it does block the gnloperation pad but never unblocks it, which causes the flush-start event to be never forwarded further downstream.
Sebastian, is this still an issue in 1.x ?
This particular issue has been fix, there are still a bit of work to be done in the flush handling in videomixer, https://bugzilla.gnome.org/show_bug.cgi?id=706441 is the place to look at.