[Bug 766835] New: [bin] race condition when a NON_PREROLL child also sends ASYNC_START

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 766835
           Summary: [bin] race condition when a NON_PREROLL child also
                    sends ASYNC_START
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: All
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: julien at moutte.net
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

Created attachment 328431
  --> https://bugzilla.gnome.org/attachment.cgi?id=328431&action=edit
Test case demonstrating race

While changing the state of a child, we might receive ASYNC_START messages
which we will store for future matching.

If that child state change returns NO_PREROLL we will ignore the ASYNC messages
and successfully change the state of the child, BUT the stored ASYNC_START
message is still there.

As the state was changed the child might not have a pending state when the
ASYNC_DONE message is sent by it's internal elements. If that happens the
ASYNC_DONE message is not propagated to the parent bin and the stored
ASYNC_START message is orphaned preventing the parent bin to complete its own
state change.

I am providing a test case demonstrating that race which has been tested with
1.6.2, 1.6.4 and 1.8.1

The test cases uses a sample JPEG file which is being opened by 2 different
bins using uridecodebin (both of them generating ASYNC_* messages) but one of
the bins also has identity with sync=TRUE which triggers a NO_PREROLL. If
there's a slight delay between changing states from PAUSED to PLAYING the
no_preroll_bin will eat the ASYNC_DONE message leaving the pipeline in a
transitioning state.

My proposed fix for this bug would be to delete stored ASYNC_START messages
from child in the parent bin when child returns NO_PREROLL (attached patch).

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.