[Bug 732866] New: udpsink blocking on g_socket_send_message()
GStreamer (bugzilla.gnome.org)
bugzilla at gnome.org
Mon Jul 7 13:44:59 PDT 2014
https://bugzilla.gnome.org/show_bug.cgi?id=732866
GStreamer | gst-plugins-good | 1.3.90
Summary: udpsink blocking on g_socket_send_message()
Classification: Platform
Product: GStreamer
Version: 1.3.90
OS/Version: Windows
Status: UNCONFIRMED
Severity: normal
Priority: Normal
Component: gst-plugins-good
AssignedTo: gstreamer-bugs at lists.freedesktop.org
ReportedBy: jake.foytik at ipconfigure.com
QAContact: gstreamer-bugs at lists.freedesktop.org
GNOME version: ---
Problem: Testing the rtsp-server on windows using the test-launch example and
randomly connecting/disconnecting multiple streams (50) from the server. After
several iterations of connecting and disconnecting, the main loop will
occasionally enter a dead-locked state.
I have localized the problem to when an rtsp-server class signals the "remove"
action on udpsink. The program will hang indefinitely on this function as it is
trying to obtain a lock on a mutex. It is unable to obtain the lock because the
gst_multiudpsink_render() function of gstmultiudpsink.c currently has the lock
and is stuck on the g_socket_send_message() function.
It appears I am creating some scenario where the g_socket_send_message() is
unexpectedly blocking. Reading the gsocket documentation, by default gsockets
are configured as blocking and do not have a timeout set. I couldn't find any
indication that the socket is configured (as non-blocking or with a timeout)
after its creation in udpsink or multiudpsink. Thus, using the gsocket in its
default configuration could seemingly allow the send_message() function to hang
indefinitely. Looking at gsocket.c, this could happen for one of the following
reasons:
- The socket never indicates it it is ready for writing and the program waits
on the g_socket_condition_wait() function.
- The WSASendTo() function repeatedly returns either a WSAEINTR or
WSAEWOULDBLOCK error, allowing the program to stay in the infinite while loop.
Since we are dealing with UDP, would it be appropriate to set the gsocket as
non-blocking and allow the send_message function to post an error?
Another option may be to have the gst_multiudpsink_remove() function trigger
the cancellable that is passed to send_message().
--
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.
More information about the gstreamer-bugs
mailing list