GNOME Bugzilla – Bug 754395
rtsp-media: prepare continues after error
Last modified: 2018-11-03 15:38:54 UTC
I've encountered the following problem with GstRTSPMedia: gst_rtsp_media_prepare() got an error in wait_preroll() and jumped to preroll_failed(). The media status had been set to GST_RTSP_MEDIA_STATUS_ERROR. gst_rtsp_media_prepare() called gst_rtsp_media_unprepare() and started unpreparing. At the same time, start_prepare() was running in another thread. It had been scheduled by default_prepare(), which had been called by gst_rtsp_media_prepare() before wait_preroll(). start_prepare() called start_preroll(), which continued to set the media pipeline to PLAYING, despite the error in the other thread. When the pipeline tried to go to READY, a gstmultiudpsink called getsockopt on a socket that had already been closed (as a result of the unprepare in the other thread). The following two excerpts of gdb backtraces show the problem (gst-rtsp-server 1.4.3): Thread 2: ...
+ Trace 235407
Created attachment 310419 [details] [review] media: state handling updates The attached suggested patch contains a fix for the problem (checking media status before calling set_state() in start_preroll()) and some other fixes concering the state lock in GstRTSPMedia: * Check state errors in more places (protecting against concurrent updates). * Protect set_state with state lock (except in finish_unprepare, where a comment explains that we release the lock for avoiding deadlocks). * Consistently do convert_range with state lock held (as it says in the comment for default_convert_range). * Clarify that default_prepare and default_setup_sdp are called with state lock.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/gstreamer/gst-rtsp-server/issues/13.