From 902a5e6bdc1a8f0b83f0a64a79581aa0831f86b0 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Tim-Philipp=20M=C3=BCller?= Date: Thu, 21 Aug 2014 14:02:16 +0100 Subject: [PATCH] queue: fix race when flush-stop event comes in whilst shutting down Don't re-start the queue push task on the source pad when a flush-stop event comes in and we're in the process of shutting down, otherwise that task will never be stopped again. When the element is set to READY state, the pads get de-activated. The source pad gets deactivated before the queue's own activate_mode function on the source pads gets called (which will stop the thread), so checking whether the pad is active before re-starting the task on receiving flush-stop should be fine. The problem would happen when the flush-stop handler was called just after the queue's activate mode function had stopped the task. Spotted and debugged by Linus Svensson https://bugzilla.gnome.org/show_bug.cgi?id=734688 --- plugins/elements/gstqueue.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-) diff --git a/plugins/elements/gstqueue.c b/plugins/elements/gstqueue.c index 30fcdc5887..c598d5a309 100644 --- a/plugins/elements/gstqueue.c +++ b/plugins/elements/gstqueue.c @@ -792,8 +792,13 @@ gst_queue_handle_sink_event (GstPad * pad, GstObject * parent, GstEvent * event) queue->srcresult = GST_FLOW_OK; queue->eos = FALSE; queue->unexpected = FALSE; - gst_pad_start_task (queue->srcpad, (GstTaskFunction) gst_queue_loop, - queue->srcpad, NULL); + if (gst_pad_is_active (queue->srcpad)) { + gst_pad_start_task (queue->srcpad, (GstTaskFunction) gst_queue_loop, + queue->srcpad, NULL); + } else { + GST_INFO_OBJECT (queue->srcpad, "not re-starting task on srcpad, " + "pad not active any longer"); + } GST_QUEUE_MUTEX_UNLOCK (queue); STATUS (queue, pad, "after flush");