[Bug 734688] queue: race when receiving flush-stop event during shutdown, task gets re-started

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=734688
  GStreamer | gstreamer (core) | git

Tim-Philipp Müller <t.i.m> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
   Target Milestone|HEAD                        |1.4.1

--- Comment #21 from Tim-Philipp Müller <t.i.m at zen.co.uk> 2014-08-23 11:59:10 UTC ---
Nice work debugging this, and thanks for the unit test!

Pushed these to master now, will cherry-pick the fix into 1.4 as well:

commit ae74a1a83a8a5034c37da283d6176c3abab4b3cc
Author: Linus Svensson <linussn at axis.com>
Date:   Wed Aug 20 12:55:51 2014 +0200

    tests: add test that triggers deadlock in state change of queue

    When receiving FLASH_STOP in a state transition to READY, a queue
    element can end up with an active task that will never end.

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

commit 93d8679b00c1402aaf44f37bb67487d1a3d0ffc4
Author: Tim-Philipp Müller <tim at centricular.com>
Date:   Thu Aug 21 14:02:16 2014 +0100

    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 at axis.com>

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


Wim's patch is independent. We might still want to refuse to start a task on a
deactivated pad, but should probably look at the code of the various users a
bit before that.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.