This is the mail archive of the cygwin-developers@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

FYI: WSADuplicateSocket breakage


I've poked around a little more on the issue with duplicating
sockets I mentioned on this list earlier in the week and it looks
like WSADuplicateSocket / WSASocket is interestingly broken on my
machine (win2k SP3).  (I've confirmed this with a raw winsock2
test program but I initially tripped over it in one of my cygwin
test programs; I've not tried any other version of windows as
yet.)  I'm not sure that this will affect any programs since the
order of operations required is weird, but here we go for the
record.

Consider the following sequence of calls (in raw winsock2 calls;
"dup" is a WSADuplicateSocket / WSASocket pair):

    sd = socket (...)
    d_sd = dup (sd)
    connect (sd, ...)

At this point, the d_sd socket doesn't seem to be connected; i.e.
getsockname fails on it with WSAEINVAL, as it does before you call
connect.

A truly more bizarre one is:

    sd = socket (...)
    d_sd = dup (sd)
    connect (sd, ...)
    setsockopt (sd, ...)
    closesocket (sd)
    dd_sd = dup (d_sd)

At this point, the dd_sd socket is sort of a duplicate of the
closed sd socket, not of the open d_sd socket.  YIKES!  That is,
certain operations on dd_sd don't get anywhere (all you get are
EINVALs, ENOTCONNs, etc.): examples I've come across are
getsockname, shutdown and recvfrom (but not recv, or send, or
sendto . . .)

BTW the call to setsockopt is important here: w/o it, dd_sd works
fine.  I've tried both SO_DEBUG and SO_LINGER for the setsockopt
call and both cause this problem.  (Obviously, the SO_LINGER call
in fhandler_socket::close is the analogue in the cygwin DLL of
this.)

I can't imagine too many people would choose such a bizarre
sequence of operations; I only discovered it by chance in a
(rather strange) test program.  I assume that this really
constitutes a reportable bug (to Microsoft) but I'm not sure I can
be bothered; if anyone else fancies reporting it, I can provide
the relevant test cases.

Now that I've convinced myself that there is a bug but that it's
unlikely to be a problem to anyone, I'll get back to something
rather more sensible.

Cheers for now,

// Conrad




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]