Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <1DB8BA4BAC88D3118B2300508B5A552CD9275B@mail.fitlinxx.com> From: David Bolen To: cygwin AT sources DOT redhat DOT com Subject: read(0) when stdin is a Windows socket handle returning EACCES Date: Fri, 14 Jul 2000 03:54:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" I'm running into a strange issue with read() failing to read from stdin when stdin is a socket connection that I was hoping someone might be able to offer any suggestions on how to further diagnose. I have a server application under NT that accepts client connections and creates a child process, connecting them to that client connection (more or less an rexec sort of thing). Fairly typical stuff. Until now it's been named pipe based, but I just added an IP (TCP) connection as an option. The problem arises when the child process being executed is a Cygwin based program (the server is not) and the incoming connecting to the server is over TCP (thus the handle supplied as stdin/stdout for the child is the socket). The Cygwin process fails to read properly from stdin, and in fact generates EACCES errors on the I/O. This is with v1.1.2 of the DLL under Windows NT 4. This small application is enough to generate the problem as target code to execute: #include #include main () { FILE *outfile = fopen("d:/tmp/ctest.out","w"); char ch; int i; while (1) { i = read(0,&ch,1); if (i < 0) { fprintf(outfile,"read error %d\n",errno); break; } else if (i == 0) { fprintf(outfile,"read EOF\n"); break; } else { fprintf(outfile,"[%02X]",ch); } fflush(outfile); } } In my test client, I'm sending the bytes 0x18 0x00 0x00 0x00 to the server. If that is run with the above code as the child process, with a named pipe connection, then the output file shows: "[18][00][00][00]read EOF", but if instead I make an IP connection to the daemon the output file from the above code shows "[18]read error 13". It gets the first byte but then gets the EACCES error. The above code aborts at that point but if I don't, I'll get EACCES continuously for every read() after that first. I haven't been able to get strace to work within the server environment (e.g., trying to get the server to execute strace which is executing the test code) and an strace of the above code on its own of course works fine. Clearly there is some behavior either happening within the cygwin DLL or by the DLL calling Win32 operations that "burps" after that first I/O when the stdin handle at process creation is a Windows socket handle, but I'm sort of stumped as to how to attack this further, so any suggestions would be appreciated. -- David /-----------------------------------------------------------------------\ \ David Bolen \ E-mail: db3l AT fitlinxx DOT com / | FitLinxx, Inc. \ Phone: (203) 708-5192 | / 860 Canal Street, Stamford, CT 06902 \ Fax: (203) 316-5150 \ \-----------------------------------------------------------------------/ -- Want to unsubscribe from this list? Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com