[gstreamer-bugs] [Bug 536856] New: rtpmanager deadlocks when receiving new data while going to NULL

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

  GStreamer | gst-plugins-bad | Ver: HEAD CVS
           Summary: rtpmanager deadlocks when receiving new data while going
                    to NULL
           Product: GStreamer
           Version: HEAD CVS
          Platform: Other
        OS/Version: All
            Status: UNCONFIRMED
          Severity: normal
          Priority: Normal
         Component: gst-plugins-bad
        AssignedTo: gstreamer-bugs at lists.sourceforge.net
        ReportedBy: ole.andre.ravnas at tandberg.com
         QAContact: gstreamer-bugs at lists.sourceforge.net
     GNOME version: Unspecified
   GNOME milestone: Unspecified


I've experienced deadlocks when changing pipeline state to NULL while pushing
the first buffer for a session. So far this has been tricky to reproduce
reliably depending on different OSes / hardware combinations.
Because of this I put together a small torture application that makes it
reliably reproducible. It hooks up an arbitrary number of simulated streams and
uses pad-probes with synchronization logic to wait for all of them to be ready
to push their first buffer, where one group is standing by to push their first
buffer into rtpbin and the other group is standing by to push the first buffer
into the sink. When all of them are ready to push they get unblocked
simultaneously by the controlling thread, and the controlling thread follows it
by an optional configurable delay and then an immediate state change to NULL.
This is repeated with an outer loop that changes that configurable delay from
none to 100 ms, with an inner loop that varies the number of streams from 1 to
128 (actually 2 to 256 in total, as it's the number of streams in each group --
one group blocking before pushing to rtpbin and the other group blocking before
pushing to the sink).
I haven't managed to make the inner loop get further than about 30, fewer if
running it in gdb or on Windows, so it's very easy to reproduce.
Will attach the test code used.


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