GNOME Bugzilla – Bug 750728
RTSP Stream deadlocks on Windows
Last modified: 2016-12-08 16:32:14 UTC
Problem: On Windows, when serving streams from rtsp-server I am frequently observing the streams lockup (stop transmitting data on the server side). The problem seems to occur more frequently if the server is under network load. I have traced the issue to multiudpsink's call to g_socket_send_message(). Further, it appears to be a race condition in gsocket that causes the WSAWaitForMultipleEvents() function to be called just after the WSAEvent structure has been cleared, resulting in an infinite wait for an FD_WRITE signal that has already occurred. Looking at rtsp-stream.c a gsocket is created and given to a udpsrc element and also given to a multiudpsink element. Does this mean that multiple threads are reading and writing to the same socket and is this safe? (refer to https://bugzilla.gnome.org/show_bug.cgi?id=705027) My tests/debugging at the gsocket level indicates that multiple threads are accessing the same socket for reading and writing which is causing the issue on Windows.
Created attachment 308207 [details] [review] socket sharing removal I have removed socket sharing between udpsink and udpsrc and that seems to fix the problem.
Reading from the same socket in one thread, and writing in another should be safe. It probably isn't in GLib because of a bug around WSAWaitForMultipleEvents. The socket sharing here is needed to make NAT traversal easier for NATs that have UDP "connection" tracking. However there is also another bug related to this, in rtspsrc at least. On Windows if we create an error by sending to the socket, it will appear as an error when receiving too. http://lists.freedesktop.org/archives/gstreamer-devel/2015-September/054334.html
The problem is still actual. I understand that it possibly is not the best solution, but I think we need "#ifdef WIN32" here until the problem exists. Because this sharing makes work with udp impossible on Windows.
This is probably the same as https://bugzilla.gnome.org/show_bug.cgi?id=762283 Can you confirm?
(In reply to Sebastian Dröge (slomo) from comment #4) > This is probably the same as > https://bugzilla.gnome.org/show_bug.cgi?id=762283 > > Can you confirm? Works well with your patch from Glib master (GSocket: Fix race conditions on Win32 if multiple threads are waiting on conditions for the same socket) on Glib-2.51.0. Checked on GStreamer 1.4.5.
Great, thanks for confirming. This patch will also be in the 1.10.3 binary release. *** This bug has been marked as a duplicate of bug 762283 ***