On Jun 15 12:07, Lev Bishop wrote: > Actually, it's very strange. It gets stuck on the setsockopt() in > fhandler_socket::close(). There's a race with the parent (which is why > it didn't happen under strace or sshd -d), but if the parent gets > round to doing its select() before the child does the close(), then > the setsockopt() does not return until after the select() returns. I > attach a short testcase which reliably demonstrates the problem for > me. It doesn't use privilege separation or non-blocking sockets, so > that is not the problem. I haven't investigated whether it's something > to do with the way the socket is duplicated into the child > (WSADuplicateSocket() versus DuplicateHandle(), and such). > > Just to spell it out: the problem shown in my testcase, is only > exibited with overlapped sockets. Non-overlapped don't have any > problem. Which is strange to me, since MSDN makes no mention of > situations where setsockopt() can block.
Erm... I tested your testcase and I can reproduce the hang only when using NON-overlapped sockets created with WSASocket(..., 0). It works fine with overlapped sockets created with select or WSASocket(..., WSA_FLAG_OVERLAPPED). I assume the above is just a typo? > I think that's as far as I'm going to go with persuing this issue. If > I need native programs to use sockets, then I'll pipe them through > socat. ACK. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
