[Bug 762086] New: pad: Race between push and (de)activate leads to data flow before events

[GStreamer (GNOME Bugzilla)]

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

            Bug ID: 762086
           Summary: pad: Race between push and (de)activate leads to data
                    flow before events
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: stian.selnes at gmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
                CC: gstreamer at pexip.com
     GNOME version: ---

Created attachment 321263
  --> https://bugzilla.gnome.org/attachment.cgi?id=321263&action=edit
Test

There is a race where data can be pushed without forwarding the sticky
events. This test will trigger a g_warning about data flow before events.

There's likely more than one race here, probably both for buffers and
events. What can happen when trying to push a buffer while changing
element state and thus (de)activating the pads is:

    1. Pads are active and buffers are flowing as normal.
    2. Element changes state and its pads are deactivated, during which
       the stored sticky events are removed.
    3. A new buffer is pushed from a srcpad in the direction of the
       element's deactive sinkpad.
    4. check_sticky() in gst_pad_push_data() will not send events since
       the flag PENDING_EVENTS on this srcpad is not set.
    5. Before calling gst_pad_chain_data_unchecked() on the sinkpad, the pad
       will be activated (because of an element state change). The flag
       PENDING_EVENTS will be set, but it's too late for the srcpad to send
       the sticky events.
    6. The event check in gst_pad_chain_data_unchecked() will fail and give
       g_warning.

Any thoughts on how this should be resolved?

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