[Bug 759773] New: Prevent simultaneous prepare/unprepare of RTSP media

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=759773

            Bug ID: 759773
           Summary: Prevent simultaneous prepare/unprepare of RTSP media
    Classification: Platform
           Product: GStreamer
           Version: git master
                OS: All
            Status: NEW
          Severity: normal
          Priority: Normal
         Component: gst-rtsp-server
          Assignee: gstreamer-bugs at lists.freedesktop.org
          Reporter: sebras at hotmail.com
        QA Contact: gstreamer-bugs at lists.freedesktop.org
     GNOME version: ---

By scripting an RTSP-client to quickly and repeatedly send DESCRIBE requests to
gst-rtsp-server and then killing each client without waiting for the full
DESCRIBE response I was able to trigger errors such as:

"GStreamer-CRITICAL **: Trying to dispose element rtpbin33722, but it is in
READY instead of the NULL state"

"g_inet_socket_address_get_address: assertion 'G_IS_INET_SOCKET_ADDRESS
(address)' failed"

And other errors related to GstRTSPThread, for which I fail to find the logs
right now.

These all stem from the fact that gst_rtsp_media_prepare() starts an idle
source to run start_prepare(), while waiting for this to finish in
wait_preroll(). Now, due to the high number of incoming requests the idle
source many not have any chance of running until _just_ after wait_preroll()
times out (20 seconds). gst_rtsp_media_prepare() will in this case run
gst_rtsp_media_unprepare(), at the same time as start_prepare() is executing.

The approach here is to take the state lock in start_prepare() and check
whether the media is still preparing, if it is, then let it prepare fully
before releasing the lock. Should the media not still be preparing the idle
source will return silently. You could of course argue that taking the lock for
the entire duration of start_prepare() is suboptimal/wrong, but I believe that
I need to do that to ensure that the entire preparation is done while
wait_preroll() is being waiting on the lock.

When running my test case with this fix I see no further problems. I'm happy to
discuss the code further if it is unclear in any way.

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