GNOME Bugzilla – Bug 759773
Prevent simultaneous prepare/unprepare of RTSP media
Last modified: 2015-12-28 12:09:55 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.
Created attachment 317781 [details] [review] Proposed patch.
commit b2abb970435e618e8475c7d8060142cec4673dbe Author: Sebastian Rasmussen <sebras@hotmail.com> 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. Fixes https://bugzilla.gnome.org/show_bug.cgi?id=759773