[Bug 732640] Windows client disconnect behavior

[GStreamer (bugzilla.gnome.org)]

https://bugzilla.gnome.org/show_bug.cgi?id=732640
  GStreamer | gst-rtsp-server | 1.3.90

--- Comment #1 from Jake Foytik <jake.foytik at ipconfigure.com> 2014-07-09 16:23:43 UTC ---
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.

-- 
Configure bugmail: https://bugzilla.gnome.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.
You are the assignee for the bug.