Mail Archives: cygwin/2009/08/13/21:58:00
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");
}
}
=====================================================
cygwin wrote:
>
> After updating 2 other systems to cygwin 1.7, I find that they also
> work fine in the same test.
> However, that doesn't help much debugging this.
>
> I found that the problem on the failing system is related to using
> Unix domain sockets for the IPC pipes.
> If I replace the socketpair() call in fd_pair() in file util.c with
> pipe(), everything works fine.
>
> int fd_pair(int fd[2])
> {
> int ret;
>
> //#ifdef HAVE_SOCKETPAIR
> // ret = socketpair(AF_UNIX, SOCK_STREAM, 0, fd);
> //#else
> ret = pipe(fd);
> //#endif
>
> if (ret == 0) {
> set_nonblocking(fd[0]);
> set_nonblocking(fd[1]);
> }
>
> return ret;
> }
>
> The fact that cygwin 1.5 works fine on this system indicates that
> something is going wrong in 1.7 cygwin1.dll triggered by some
> conditions on this particular system.
>
>
>
>
> Corinna Vinschen wrote:
>> On Aug 13 13:17, cygwin wrote:
>>
>>> The RSYNC application fails in close() on the pipe streams to and
>>> from child processes created when rsync starts.
>>> When running rsync.exe and cygwin1.dll from cygwin 1.5 within the
>>> 1.7 installation on the same system (WinXP pro),
>>> the identical invocation completes without errors.
>>>
>>> The problems appears to be a bug in the cygwin.dll
>>>
>>> For example,
>>>
>>> $ rsync -a /etc /test
>>>
>>> produces the following messages:
>>>
>>> rsync: Failed to dup/close: Socket operation on non-socket (108)
>>> rsync error: error in IPC code (code 14) at pipe.c(147)
>>> [receiver=3.0.5]
>>> rsync: read error: Connection reset by peer (104)
>>> rsync error: error in IPC code (code 14) at io.c(759) [sender=3.0.5]
>>>
>>
>> I tested the exact above command with cygwin 1.7-0-58 and rsync-3.0.5-1
>> on Windows 7, WIndows Server 2008 SP2, as well as on XP SP3.
>>
>> Works fine for me on all three systems.
>>
>>
>> Corinna
>>
>>
>
>
--
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
- Raw text -