Message-ID: <4A84EBB4.5050502@sipxx.com>
Date: Fri, 14 Aug 2009 00:44:36 -0400
From: cygwin <karl@sipxx.com>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: cygwin@cygwin.com
CC: cygwin@sipxx.com
Subject: Re: Cygwin1.dll 1.7.0-5x: RSYNC failures in close() system call on  	pipe  file descriptors
References: <4A844A97.1050809@sipxx.com> <20090813183053.GU13438@calimero.vinschen.de> <4A848D0A.1000900@sipxx.com> <4A84C48E.9070006@sipxx.com> <4A84C671.3050309@sipxx.com>
In-Reply-To: <4A84C671.3050309@sipxx.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

Further tests with this little program show that the observed error only 
occurs when the socket is dup()'ed to STDIN (fd = 0), but not when 
dup'ed to any other fd number. To test, replace STDIN_FILENO in the dup 
call with any positive integer (except 3 and 4).
Also, explicitly closing STDIN in advance of the dup call has no effect, 
as it should since dup should close exisiting fd automatically.
This moves the problem area at least down into  dtable::dup_worker and 
build_fh_pc()
how is STDIN handled differently?


cygwin wrote:
> I forgot to add that the same binary copy of the executable of the 
> test program (compiled under 1.7) works without error if I place the 
> cygwin1.dll version 1.5 into the same directory.
>
>
> cygwin wrote:
>>
>> I wrote a small test program to isolate the problem from RSYNC.
>> The problem occurs when a file descriptor obtained from socketpair()  
>> is dup2()'ed into STDIN and then closed. The close call fails.
>> Output from the program is as follows:
>>
>> socket 1 = 3
>> socket 2 = 4
>> dup2 socket 1...
>> closing socket 1...
>> close: Socket operation on non-socket
>> closing socket 1 failed
>>
>>
>> It is interesting to note that the close() is successful when the 
>> dup2 calling sequence is omitted.
>> Since socketpair() in cygwin appears to use AF_INET sockets to 
>> simulate AF_UNIX it might be interesting to try this on a single INET 
>> socket.
>>
>>
>>
>> ===============================================
>> #include <stdio.h>
>> #include <stdlib.h>
>> #include <unistd.h>
>> #include <sys/socket.h>
>>
>> main()
>> {
>>        int fd[2];
>>        int res = socketpair(AF_UNIX, SOCK_STREAM, 0, fd);
>>        if (res < 0) {
>>                perror("socketpair");
>>                fprintf(stderr, "socketpair failed\n");
>>                exit(1);
>>        }
>>
>>        fprintf(stderr, "socket 1 = %d\n", fd[0]);
>>        fprintf(stderr, "socket 2 = %d\n", fd[1]);
>>
>>        fprintf(stderr, "dup2 socket 1...\n");
>>        res = dup2(fd[0], STDIN_FILENO);
>>        if (res < 0) {
>>                perror("dup2");
>>                fprintf(stderr, "dup2 failed\n");
>>        }
>>
>>        fprintf(stderr, "closing socket 1...\n");
>>        res = close(fd[0] < 0);
>>        if (res < 0) {
>>                perror("close");
>>                fprintf(stderr, "closing socket 1 failed\n");
>>        }
>> }
>> =====================================================
>>
>
>


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple