I've been noticing a bug specifically in Python 2.5 concerning the socket library when using SOCK_DGRAM.  I was trying to use python as an SNTP client.  I used several implementations including the Python cookbook version (http://www.google.com/url?sa=t&ct=res&cd=2&url=http%3A%2F%2Faspn.activestate.com%2FASPN%2FCookbook%2FPython%2FRecipe%2F117211&ei=6kp8RvyPMsLAiwGr6fzdDg&usg=AFQjCNHaRhf2_o5Si1SIqeQue1_aylJxsA&sig2=DzpLAKAFiol-b_sc0HAc5A) and this other version (http://ntrg.cs.tcd.ie/~argp/software/attic/ntpdate.py).  They each exhibited a strange problem where the first info received is not what is expected.  This subsequently causes an error when the struct.unpack function is used because python for some reason receives much more than 48 bytes of info.  Here is an example of the erroneous info received: http://stashbox.org/25082/output.pdf

I've discovered a workaround for this bug.  It only works in Python 2.5.  In earlier versions, it causes the script to hang.  If one calls the function client.recvfrom(1024) twice and ignores the data received first, the second time it is called, it'll have the expected info.

I've also devised a way that the bug can be avoided in version 2.5 while not causing earlier versions to hang.

for i in range(2):
	client.sendto(data, (sys.argv[1], 123))
	data, address = client.recvfrom(1024)

Anyway, I believe this is a problem in the socket library that only manifests itself when using UDP.

Thanks for looking into it.

Could you produce a small runnable sample, describe what it should produce, and what it actually produces?  That would make it much easier for us to help you.  Thank you.