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 663701 - videomixer: deadlock in stream lock
videomixer: deadlock in stream lock
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-editing-services
unspecified
Other Linux
: Normal critical
: 1.3.3
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2011-11-09 16:04 UTC by Mateu Batle
Modified: 2014-06-22 13:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Backtrace of deadlock (38.00 KB, text/plain)
2011-11-09 16:04 UTC, Mateu Batle
Details

Description Mateu Batle 2011-11-09 16:04:48 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.
Comment 1 Sebastian Dröge (slomo) 2011-11-24 08:32:49 UTC
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.
Comment 2 Edward Hervey 2013-08-26 08:13:20 UTC
Sebastian, is this still an issue in 1.x ?
Comment 3 Thibault Saunier 2013-11-16 23:37:42 UTC
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.