[Bug 679950] New: [pad] gst_pad_set_blocked_async in rare cases calls callback twice

[GStreamer (bugzilla.gnome.org)]

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

           Summary: [pad] gst_pad_set_blocked_async in rare cases calls
                    callback twice
    Classification: Platform
           Product: GStreamer
           Version: 0.10.36
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: major
          Priority: Normal
         Component: gstreamer (core)
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: www at saepia.net
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Created an attachment (id=218841)
 --> (https://bugzilla.gnome.org/attachment.cgi?id=218841)
Log

I am developing application with GStreamer 0.10.36 (default install from ubuntu
12.04) that dynamically builds and changes during runtime quite complex
pipelines (30+ elements, a few adders, tee, quite a lot of queues2, a few
decodebins2). Its structure is attached to this bug report as both DOT dump
file and PNG.

I've run into strange situation - one of the subbins starts to dynamically
unlink itself. During this process it asynchronously blocks pad to prevent flow
errors.

In rare cases callback to gst_pad_set_blocked_async calls callback twice, from
two different threads. Log with GST_SCHEDULING:5 is attached. I am unable to
produce *:5 log, as it slow downs the application and problem disappears,
propably because such slow down can affect concurrent locking issues.

The code of callback is here
http://bazaar.launchpad.net/~tuned-dev/tuned-patchbay/puregst/view/head:/src/pipeline/sources/source-base.vala
(please ensure that you look at rev 113), line 345. The function that is
responsible for detaching is invoked by shutdown().

If you check the attached log, you can see that callback is invoked twice
(lines 20613 & 20623).



I have example that triggers this bug, so I can reproduce it locally. As it is
quite complex and the bug does not appear if the pipeline is simpler, I am
unable to just provide code snippet. If you want, I can install it on some VPS
and provide you a credentials or create virtual machine image and upload it
somewhere.

For me it seems that pad locking during gst_pad_push_data() in gstpad.c is
buggy, but I am not GStreamer internals expert.

I've seen that in the source code of gstpad.c there's a FIXME near 

  /* FIXME: this check can go away; pad_set_blocked could be implemented with
   * probes completely or probes with an extended pad block. */
  while (G_UNLIKELY (GST_PAD_IS_BLOCKED (pad)))
    if ((ret = handle_pad_block (pad)) != GST_FLOW_OK)

I've also seen that in GStreamer 0.11 pad blocking in gstpad.c is completely
refactored.

0.10 will be in production use for quite a long time even if new version will
be released, so maybe it is worth to fix that?

I can spend some time on investigating the issue, but I will appreciate any
help and suggestions before I start. Maybe it is just possible to backport the
code from 0.11?

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