Created attachment 218841 [details]
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?