[Bug 668254] New: [pad] possible race between FLUSH_STOP and pad deactivation

[GStreamer (bugzilla.gnome.org)]

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

           Summary: [pad] possible race between FLUSH_STOP and pad
                    deactivation
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: mnauw at users.sourceforge.net
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=205612)
 View: https://bugzilla.gnome.org/attachment.cgi?id=205612
 Review: https://bugzilla.gnome.org/review?bug=668254&attachment=205612

pad: also flush FLUSH_STOP if pad not active

Consider a FLUSH_STOP moving through the pipeline in one thread, while other
thread (mainloop) is performing PAUSED_TO_READY.  While such behaviour is
typically rare (FLUSH_STOP usually occurs with seeking and done by mainloop),
it is (AFAIK) not "illegal" and can in fact occur in e.g. GNonLin context.

The following race can occur:
* mainloop performs pre_activate for src pad
* mainloop performs queue src pad (de)activation 
(setting src result, unblocking loop etc)
* core processes FLUSH_STOP for sink pad; it notices that pad has been
deactivated so will not clear flush flag, but afaics it will still invoke the
pad's event function

* processing an event while flushing is Not Good.  For queue-like elements,
this could also mean loop task being started again and so even worse.
Particularly so when mainloop then performs src pad post_activate, which tries
to get STREAM_LOCK (and will not get since a task is running).

Looks like this has been fixed in 0.11 (slightly differently); would seem to be
proper in 0.10 as well unless there is some behaviour to maintain there.

-- 
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.