diff options
| author | Tim-Philipp Müller <tim@centricular.com> | 2014-08-21 14:02:16 +0100 |
|---|---|---|
| committer | Tim-Philipp Müller <tim@centricular.com> | 2014-08-23 11:43:20 +0100 |
| commit | 93d8679b00c1402aaf44f37bb67487d1a3d0ffc4 (patch) | |
| tree | 9e2cc3cc8716124f07c044bae896b37b9709d013 | |
| parent | 86d7a597f00b7e1a6619cf566bfb27adb7f3f8c2 (diff) | |
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
| -rw-r--r-- | plugins/elements/gstqueue.c | 9 |
1 files 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"); |