[gstreamer-bugs] [Bug 164168] circular pipeline fails to negotiate

bugzilla-daemon at bugzilla.gnome.org bugzilla-daemon at bugzilla.gnome.org
Sat Jul 16 02:42:10 PDT 2005


Please DO NOT reply to this by email. All additional comments should be made in
the comments box of this bug report.

 http://bugzilla.gnome.org/show_bug.cgi?id=164168
 GStreamer | gstreamer (core) | Ver: HEAD CVS

wingo at pobox.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wim at fluendo.com
           Severity|minor                       |normal
             Status|UNCONFIRMED                 |NEW
      everconfirmed|0                           |1
            Summary|[threads/opt] failed assert |circular pipeline fails to
                   |in opt                      |negotiate
   Target Milestone|HEAD                        |0.9.x



------- Additional Comments From wingo at pobox.com  2005-07-16 09:42 -------
In 0.9, this deadlocks when linking. gst_pad_link_prepare will grab the object
lock of both pads in a link, and then sequentially call get_caps_unlocked on
both of them. get_caps_unlocked will release the object lock, call the pad's
getcaps function, then reacquire the lock. However while e.g. the lock is
released on the src pad, the sink pad's lock is still held. So if one pad,
during the course of its getcaps, ends up coming back to getting its peer's
caps, negotiation will lock up.

Of course there is the IN_GETCAPS flag that's designed to prevent this from
happening, but you can't read it if the object's lock is taken, which in this
case it is, from pad_link_prepare.

Besides that, there's the question of what this pipeline should do. Because
neither pad will start a task, this should go to PLAYING but not do anything.
Dude, where's my dataflow?

Copying wim for comment, renaming, severity normal, retargeting to 0.9.x (the
link_prepare having locks *is* a bug).

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




More information about the Gstreamer-bugs mailing list