GNOME Bugzilla – Bug 732640
Windows client disconnect behavior
Last modified: 2018-01-13 16:06:04 UTC
Summary: When testing gst-rtsp-server using the test-launch example, I am seeing odd behavior with how the server handles disconnects on Windows. Test Setup: - Using test-launch example on Windows with pipeline : videotestsrc ! jpegenc ! rtpjpegpay - Connect multiple clients to the server using a script running multiple instances of playbin. (Seems to happen reliably with more than 10 streams) - Close all playbin instances. Observed behaviour: - With the server running on Linux, all of the sessions within the server were immediately detected as closed by the RTSPWatch and the closed() function of rtsp-client was triggered. The sessions are closed quickly. - With the server running on Windows, some sessions disconnected in the same manner as the Linux server (fast), however others catch errors from udpsrc indicating a flow error: rtspmedia rtsp-media.c:1788:default_handle_message: got error Could not read from resource. (gstudpsrc.c(573): gst_udpsrc_create (): /GstPipeline:media-pipeline/GstUDPSrc:udpsrc20: receive error -1: Error receiving message: An existing connection was forcibly closed by the remote host.) rtspmedia rtsp-media.c:1487:gst_rtsp_media_set_status: setting new status to 5 It appears the RTSPWatch is not always detecting the closure of a connection on Windows. The abnormal disconnection process seems to take longer and blocks any incoming connection requests making the rtsp server unresponsive.
On further inspection, the RTSPWatch is functioning properly. I am seeing the closed() function of rtsp-client being called immediately as the connection is dropped. However, I am still seeing udpsrc errors on the pipeline which indirectly cause the server to crash. Using the same test setup described above, when disconnecting 10 cameras simultaneously from the rtsp-server it sometimes segfaults on the g_source_destroy() call in the finish_unprepare() function. Here is the sequence of events that lead to the crash: - Disconnect 10 clients - closed() function of rtsp-client is triggered which eventually calls finish_unprepare. - while the unprepare functions are holding the state_lock mutex, an error message is received from the pipeline and the bus_message() function waits to get a lock on state_lock. - finish_unprepare completes and sets the state to UNPREPARED, releases state_lock - the error message is then handled by bus_message, resulting in the state being set to ERROR - gst_rtsp_media_unprepare() is called again and sees the state is not already UNPREPARED and continues to call finish_unprepare again which results in a segfault. Possible solutions: - Do not allow the rtsp-media state to transition from UNPREPARED to ERROR. This would prevent finish_unprepare from being called multiple times. - Have the bus_message() function in rtsp-media ignore messages if the media is in the UNPREPARED state.
This sounds like something we fixed a while back - do you still get this with recent versions of GStreamer? (Sorry no one got to look at this earlier)
I am still seeing segfaults when simultaneously disconnecting streams. I do not think the problem is limited to Windows and I think this issue is linked to a race condition in rtsp-media:finish_unprepare() (https://bugzilla.gnome.org/show_bug.cgi?id=755329)
Does this bug disappear for you with your patch from the other bug?
Closing this bug report as no further information has been provided. Please feel free to reopen this bug report if you can provide the information that was asked for in a previous comment. Thanks!