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 <linux.svensson@axis.com>

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

diff --git a/plugins/elements/gstqueue.c b/plugins/elements/gstqueue.c
index 30fcdc588711741a1ac288f0112dbce24311e802..c598d5a309a71185cb2351ec1704d939fec8ef0c 100644 (file)
--- 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");