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...