[Bug 754395] New: rtsp-media: prepare continues after error

["GStreamer" (GNOME Bugzilla)]

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

Bug ID: 754395
Summary: rtsp-media: prepare continues after error
Classification: Platform
Product: GStreamer
Version: git master
OS: Linux
Status: NEW
Severity: normal
Priority: Normal
Component: gst-rtsp-server
Assignee: gstreamer-***@lists.freedesktop.org
Reporter: ***@axis.com
QA Contact: gstreamer-***@lists.freedesktop.org
GNOME version: ---

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:

...
#11 0x7787e894 in finish_unprepare (media=0x63973b60) at rtsp-media.c:2420
#12 0x7788309c in gst_rtsp_media_unprepare (media=0x63973b60) at
rtsp-media.c:2529
#13 0x77883390 in gst_rtsp_media_prepare (media=0x63973b60, thread=0x5f1c8968)
at rtsp-media.c:2391
#14 0x778959a0 in find_media (client=0xa7ac80, ctx=0x683febc8, path=0x61bc4e68
"/axis-media/media.amp", matched=0x0) at rtsp-client.c:625
#15 0x7789941c in handle_describe_request (ctx=0x683febc8, client=0xa7ac80) at
rtsp-client.c:2076
#16 handle_request (request=<optimized out>, client=0xa7ac80) at
rtsp-client.c:2412
#17 gst_rtsp_client_handle_message (client=0xa7ac80, message=<optimized out>)
at rtsp-client.c:2978
#18 0x77d411e0 in gst_rtsp_source_dispatch_read (stream=<optimized out>,
watch=0xaaad00) at gstrtspconnection.c:3279
...

Thread 1:

...
#1 0x004194c8 in getsockopt (sockfd=323, level=<optimized out>,
optname=<optimized out>, optval=<optimized out>, optlen=0x5c2feb0c) at
monolith/src/main.c:155
#2 0x7455afec in gst_multiudpsink_start (bsink=0x6cf2f7f0) at
gstmultiudpsink.c:1365
#3 0x77838960 in gst_base_sink_change_state (element=0x6cf2f7f0,
transition=GST_STATE_CHANGE_NULL_TO_READY) at gstbasesink.c:4901
#4 0x7778578c in gst_element_change_state (element=0x6cf2f7f0,
transition=<optimized out>) at gstelement.c:2602
#5 0x77785bd8 in gst_element_set_state_func (element=0x6cf2f7f0,
state=<optimized out>) at gstelement.c:2558
#6 0x77765d54 in gst_bin_element_set_state (next=GST_STATE_READY,
current=<optimized out>, start_time=18446744073709551615, base_time=0,
element=0x6cf2f7f0, bin=0x63957358) at gstbin.c:2328
#7 gst_bin_change_state_func (element=0x63957358,
transition=GST_STATE_CHANGE_NULL_TO_READY) at gstbin.c:2665
#8 0x7778578c in gst_element_change_state (element=0x63957358,
transition=<optimized out>) at gstelement.c:2602
#9 0x77785bd8 in gst_element_set_state_func (element=0x63957358,
state=<optimized out>) at gstelement.c:2558
#10 0x7787e5fc in start_preroll (media=0x63973b60) at rtsp-media.c:2100
#11 0x7787f230 in start_prepare (media=0x63973b60) at rtsp-media.c:2179
#12 0x775ec0dc in g_main_dispatch (context=0x6a8c1e00) at gmain.c:3064

["GStreamer" (GNOME Bugzilla)]

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

David Svensson Fors <***@axis.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@axis.com

--- Comment #1 from David Svensson Fors <***@axis.com> ---
Created attachment 310419
--> https://bugzilla.gnome.org/attachment.cgi?id=310419&action=edit
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.

["GStreamer" (GNOME Bugzilla)]

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

GStreamer system administrator <***@gstreamer.net> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |OBSOLETE

--- Comment #2 from GStreamer system administrator <***@gstreamer.net> ---
-- 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.