Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-developers-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin-developers/>
List-Post: <mailto:cygwin-developers AT cygwin DOT com>
List-Help: <mailto:cygwin-developers-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-developers-owner AT cygwin DOT com
Delivered-To: mailing list cygwin-developers AT cygwin DOT com
Message-ID: <097e01c2456d$43e8b070$6132bc3e@BABEL>
From: "Conrad Scott" <Conrad DOT Scott AT dsl DOT pipex DOT com>
To: <cygwin-developers AT cygwin DOT com>
Subject: FYI: WSADuplicateSocket breakage
Date: Fri, 16 Aug 2002 22:38:30 +0100
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000

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