Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com Message-ID: <015e01c243ce$8390e3f0$6132bc3e@BABEL> From: "Conrad Scott" To: Subject: getsockname / recvfrom bug (?) Date: Wed, 14 Aug 2002 21:09:36 +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 Having changed the socket code to use recvfrom, I've now found an apparent bug whereby recvfrom will fail with WSAEINVAL. This was already a problem in cygwin (AFAICT) but my change to make all reads use recvfrom has made it potentially more troublesome. (Interestingly, I see the same problem with getsockname but not, e.g., with recv, or send, or sendto even). Anyhow the problem occurs if you dup(2) a socket and then operate on the duplicate copy w/o closing the original socket and without forking; i.e. it's unlikely that anything will be affected since dup'ing a socket is normally followed by one or both of those two actions, and then the bug doesn't show. I'm just writing a raw winsock2 program to check what's going on but I thought I'd bring it to Chris and Corinna's attention particularly, in case they'd rather not release that last patch of mine until I've found some workaround. As I said, it's not a new bug and it's only exposed under slightly wierd circumstances, but I've made it a little more likely to happen. As soon as I've any more information on this, I'll get back to the list. BTW, if this is a "well known" problem, I'd be interested in that information too (and yes, I''ve checked the mailing list archives to no avail as yet). Cheers, // Conrad