After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 759773 - Prevent simultaneous prepare/unprepare of RTSP media
Prevent simultaneous prepare/unprepare of RTSP media
Product: GStreamer
Classification: Platform
Component: gst-rtsp-server
git master
Other All
: Normal normal
: 1.7.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2015-12-22 12:06 UTC by Sebastian Rasmussen
Modified: 2015-12-28 12:09 UTC
See Also:
GNOME target: ---
GNOME version: ---

Proposed patch. (2.41 KB, patch)
2015-12-22 12:07 UTC, Sebastian Rasmussen
committed Details | Review

Description Sebastian Rasmussen 2015-12-22 12:06:22 UTC
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.
Comment 1 Sebastian Rasmussen 2015-12-22 12:07:17 UTC
Created attachment 317781 [details] [review]
Proposed patch.
Comment 2 Sebastian Dröge (slomo) 2015-12-28 12:09:33 UTC
commit b2abb970435e618e8475c7d8060142cec4673dbe
Author: Sebastian Rasmussen <>
Date:   Tue Dec 22 12:08:02 2015 +0100

    rtsp-media: Do not prepare media after media times out
    Deferred calls to start_prepare() can be deferred past the point until
    which wait_preroll() and by proxy gst_rtsp_media_get_status() is
    prepared to wait. Previously there was no lock and no check for this
    situation. This meant that a media could be prepared and unprepared
    simultaneously by two different threads. Now a lock is in place and a
    suitable check is done.