[gstreamer-bugs] [Bug 548764] New basetransform doesn't lock pad properly when looking at its caps

[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=548764

  GStreamer | gstreamer (core) | Ver: HEAD CVS

Olivier Crete (Tester) changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEEDINFO                    |UNCONFIRMED




------- Comment #6 from Olivier Crete (Tester)  2008-09-10 17:14 UTC -------
Yes, it should really be a blocker.

Sadly, I don't have a "simple" test case. The test case involves running all of
farsight2.

To reproduce:
get farsight2 0.0.3 (or the git trunk) and build it

cd tests/gui
G_DEBUG=fatal-warnings python fs2-gui.py
click "New Server"
in another term, do the same thing.. but click "Connect" to connect to the
server
Watch video being transfered between both sides.
Try changing the video codec on one side or on the other side..
Enjoy crash.

The way I see it is quite simple.. Either GST_PAD_CAPS() is protected by the
stream lock or by the object lock. If its the stream lock .. the GstPad should
be fixed, if its the object lock, the basetransform should be fixed.


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