[Gstreamer-bugs] [Bug 109797] New - gstudpsrc closes a random file if 'control' property is 'none'

[bugzilla-daemon at widget.gnome.org]

Please do not reply to this email- if you want to comment on the bug, go to the
URL shown below and enter your comments there.

http://bugzilla.gnome.org/show_bug.cgi?id=109797

Changed by janzen at pixelmetrix.com.

--- shadow/109797	Wed Apr  2 12:09:08 2003
+++ shadow/109797.tmp.32344	Wed Apr  2 12:09:08 2003
@@ -0,0 +1,44 @@
+Bug#: 109797
+Product: GStreamer
+Version: 0.6.0
+OS: Linux
+OS Details: 
+Status: NEW   
+Resolution: 
+Severity: critical
+Priority: Normal
+Component: gst-plugins
+AssignedTo: gstreamer-maint at bugzilla.gnome.org                            
+ReportedBy: janzen at pixelmetrix.com               
+QAContact: gstreamer-maint at bugzilla.gnome.org
+TargetMilestone: 0.6.x
+URL: 
+Summary: gstudpsrc closes a random file if 'control' property is 'none'
+
+In the gstudpsrc plugin, if the 'control' property is set to 'none', the
+plugin may close a randomly selected file descriptor when
+gst_udpsrc_close() is called.
+
+In my application the symptom was that, after calling gst_init(), anything
+I wrote to stdout would disappear.  Clearly something was making an
+unwanted call to close(1).  This appeared to be happening inside a thread,
+since a) strace didn't show any close(1) call, and b) running my
+application under GDB (which changes the timing of threads) would cause the
+missing stdout output to reappear; therefore, I suspected a plugin.
+
+A bit of grepping through the plugin code turned up the culprit:  There is
+an uninitialized 'control_sock' variable in sys/udp/gstudpsrc.c, which is
+passed to close() in gst_udpsrc_close().  I have no idea why this would be
+called from gst_init(); but fixing up the plugin code so that it
+initializes 'control_sock' (and 'sock', for good measure) to -1, then tests
+for this value before attempting to close a socket, corrects the problem.
+
+While we're at it, it also turns out that in a couple of places the address
+field length passed to recvfrom() is not initialized correctly to
+sizeof(struct sockaddr).  This appears not to cause trouble on Linux, but
+may cause platform-dependent oddities elsewhere.
+
+I don't know whether there's still time to get this patch into 0.6.1, but
+it seems a rather serious (though rarely occurring) bug, since in my case
+important data was being lost, and in general any file descriptor at all
+could conceivably be closed by this bug.  Thanks in advance for reviewing...