GNOME Bugzilla – Bug 700868
videomixer: Multiple locking error
Last modified: 2014-11-01 15:36:20 UTC
There is few locking error in videomixer that are visible from GNonLin unit test. To produce them run: GST_CHECKS=test_complex_operations_bis make gnl/gnloperation.gdb I have patch coming fro two cases (running multiple time give multiple results).
Created attachment 245093 [details] [review] [PATCH] videomixer: Don't hold object lock while sending events https://bugzilla.gnome.org/show_bug.cgi?id=700868 --- gst/videomixer/videomixer2.c | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-)
Created attachment 245094 [details] [review] [PATCH] videomixer: Don't hold stream-lock while pushing non-serialized events https://bugzilla.gnome.org/show_bug.cgi?id=700868 --- gst/videomixer/videomixer2.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
Created attachment 245095 [details] SVG Showing a pipeline that won't preroll There is a third case I reproduced from time to time, but can't figure-out yet. It's case where the pipeline won't preroll. Attached, you'll find an SVG showing the pipeline state.
Created attachment 245096 [details] [review] videomixer: Release COLLECT_PAD_STREAM lock when sending eos It create deadlock in case we get a flush_stop while we are sending it.
Comment on attachment 245096 [details] [review] videomixer: Release COLLECT_PAD_STREAM lock when sending eos What's the exact scenario here? gst_pad_push_event() should just return immediately when something downstream is flushing. And receiving flush-stop from upstream should not be relevant here
Comment on attachment 245094 [details] [review] [PATCH] videomixer: Don't hold stream-lock while pushing non-serialized events commit d8c5e316576a00c2ed7b37689c87b838c16c7305 Author: Nicolas Dufresne <nicolas.dufresne@collabora.co.uk> Date: Wed May 22 21:01:48 2013 -0400 videomixer: Don't hold stream-lock while pushing non-serialized events https://bugzilla.gnome.org/show_bug.cgi?id=700868
Comment on attachment 245093 [details] [review] [PATCH] videomixer: Don't hold object lock while sending events commit a7e0f251cac28743d3a7e878171ebffa8c2d6fd0 Author: Nicolas Dufresne <nicolas.dufresne@collabora.co.uk> Date: Wed May 22 21:00:45 2013 -0400 videomixer: Don't hold object lock while sending events https://bugzilla.gnome.org/show_bug.cgi?id=700868
(In reply to comment #4) > Created an attachment (id=245096) [details] [review] > videomixer: Release COLLECT_PAD_STREAM lock when sending eos > > It create deadlock in case we get a flush_stop while we are sending it. That is strange, a flush-start event should have had unblocked that. Is it an eos sent in gnlcomposition from eos_main_thread() ? This could explain, gnlcomp get an EOS, instead of checking if it's the end and forward it, it fire the g_idle_add, and figure-out if it's the end from there, which is racy. Other possibility is that the pipeline was not linked completly when flush-start was sent, but I don't think this patch is correct.
Thibault, is that third patch still needed, or we can close that bug now ?
Thibault?
There is still a locking issue happening with videomixer in the gnl tests, I still have to investigate it.
Comment on attachment 245096 [details] [review] videomixer: Release COLLECT_PAD_STREAM lock when sending eos FLUSH_STOP and EOS are both serialized events, so they should never fight over the stream lock and deadlock. Before the FLUSH_STOP there should've been a FLUSH_START that unlocks the streaming threads everywhere and makes all pads return GST_FLOW_FLUSHING. So this patch doesn't seem right and more like hiding a different bug.
Anything left here ?
There is no chance we come back to work on videomixer, the end solution endup being it's successor "compositor" base on Aggregator base class.