[gstreamer-bugs] [Bug 547352] race condition with GstPadBufferAllocFunction

[GStreamer (bugzilla.gnome.org)]

If you have any questions why you received this email, please see the text at
the end of this email. Replies to this email are NOT read, please see the text
at the end of this email. You can add comments to this bug at:
  http://bugzilla.gnome.org/show_bug.cgi?id=547352

  GStreamer | gstreamer (core) | Ver: HEAD CVS

Antoine Tremblay changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hexa00 at gmail.com




------- Comment #6 from Antoine Tremblay  2008-11-17 16:27 UTC -------
By adding in gstpad.c:gst_pad_alloc_buffer_full (GstPad

GST_PAD_STREAM_LOCK (peer);
ret = bufferallocfunc (peer, offset, size, caps, buf);
GST_PAD_STREAM_UNLOCK (peer);

When basetransform calls pad_bufferalloc on the queue srcpad
the queue tries to call it on it's src pad too and thus it calls
gst_pad_alloc_buffer_full with the queue src pad this blocks
since it requires the src pad lock and it's busy doing a push...

This in turn causes the queue not to work properly since it will 
always wait for the current element to return from it's push
before the preceding element can allocate a buffer and send it to the queue.

So the queue blocks as if there was no queue.

We need a better fix...


-- 
See http://bugzilla.gnome.org/page.cgi?id=email.html for more info about why you received
this email, why you can't respond via email, how to stop receiving
emails (or reduce the number you receive), and how to contact someone
if you are having problems with the system.

You can add comments to this bug at http://bugzilla.gnome.org/show_bug.cgi?id=547352.