[Bug 650916] New: REGRESSION: ssrcdemux causing FLOW_NOT_LINKED

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=650916
  GStreamer | gst-plugins-good | git

           Summary: REGRESSION: ssrcdemux causing FLOW_NOT_LINKED
    Classification: Platform
           Product: GStreamer
           Version: git
        OS/Version: All
            Status: UNCONFIRMED
          Severity: critical
          Priority: Normal
         Component: gst-plugins-good
        AssignedTo: gstreamer-bugs at lists.freedesktop.org
        ReportedBy: havard.graff at tandberg.com
         QAContact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---


Basically the problem is this one:

1bf94a92b04e4b0ff83fd015daa46e880cc4d920
If the lock is not released before emitting a signal, it may cause a deadlock
if any other function in the element is called. Also removed an unused
timestamp parameter https://bugzilla.gnome.org/show_bug.cgi?id=649617

What happens:

1. One rtp and one rtcp packet arrives at the same time inside the ssrcdemux
2. Both call find_or_create_demux_pad_for_ssrc (), but only the "rtcp-thread"
proceeds to create the pad, because of the Lock
3. The "rtcp-thread" that created the pad takes a little break just after
releasing the lock.
4. This gives the "rtp-thread" time to take the lock, check for the now
existing pad, and go on to push on this pad.
5. However, since the linking of the pad to the rtpjitterbuffer happens inside
the g_signal_emit of SIGNAL_NEW_SSRC_PAD, and this has not yet happened in the
"rtcp-thread" (remember it is still on a little break), the push will fail with
UNLINKED

Also, I am puzzled that the designated GST_PAD_LOCK is swapped for
GST_OBJECT_LOCK inside the find_or_create_demux_pad_for_ssrc () function? This
means that the demux->srcpads list can have elements added to it while it is
being iterated another place = dangerous stuff.

My suggestion would be to swap GST_OBJECT_LOCK for GST_PAD_LOCK and keep
holding it until the pad has been linked. (pretty much what the old behavior
was)

Is it an actual observed deadlock that has taken place that these changes are
trying to fix?

Our tests went blood red after syncing this patch, so I believe this is
something that all users of RtpBin will experience sooner or later.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.