After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 109797 - [0.6.1 candidate] gstudpsrc closes a random file if 'control' property is 'none'
[0.6.1 candidate] gstudpsrc closes a random file if 'control' property is 'none'
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins
0.6.0
Other Linux
: Normal critical
: 0.6.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 109064 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2003-04-02 17:09 UTC by janzen
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to avoid closing random file descriptors in gstudpsrc.c (2.38 KB, patch)
2003-04-02 17:10 UTC, janzen
none Details | Review

Description janzen 2003-04-02 17:09:08 UTC
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...
Comment 1 janzen 2003-04-02 17:10:00 UTC
Created attachment 15395 [details] [review]
Patch to avoid closing random file descriptors in gstudpsrc.c
Comment 2 Ronald Bultje 2003-04-06 22:20:01 UTC
*** Bug 109064 has been marked as a duplicate of this bug. ***
Comment 3 Ronald Bultje 2003-04-06 22:21:46 UTC
Fixed in HEAD. Marking for 0.6.1. Since 109094 is also contained in
this patch, I've marked it as a duplicate even though the bug isn't
directly related.
Comment 4 Ronald Bultje 2003-04-07 17:10:29 UTC
Fixed in 0.6.1 CVS.