This is the mail archive of the cygwin-patches@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Workaround patch for MS CLOSE_WAIT bug


Pierre A. Humblet wrote in
http://cygwin.com/ml/cygwin-patches/2002-q2/msg00039.html

>Weird behavior (details on request) can also be avoided by
>"closing on fork" the main sock after line (1) and deleting
>line (2).

This is an explanation for the record.
Systems: Win98 & WinME
Start a standalone sshd. From localhost or another machine launch
3 ssh sessions, in the order 1, 2, 3. Exit from #2 then from #1.
#3 is then reset unexpectedly.

Analysis: sshd has a daemon running and 3 forked workers. The workers
have a duplicated listen socket, which they closed, and an active i/o
socket. The daemon has an active listen socket. It doesn't matter if
the 3 accepted sockets are closed or not in the daemon, so this problem
is distinct from the MS CLOSE_WAIT bug.

Fix (arrived at experimentally): do not duplicate the listen socket
in the workers (they immediately close it anyway). It must be the case 
that cleaning up the duplicated sockets (improperly closed  by MS) when
the  subprocesses exit out of order exposes another MS bug.

It is serendipity that the "close on fork" approach developed for
the CLOSE_WAIT bug also takes care of this one.

The problem does not occur [more precisely, is hard to reproduce]
when the workers are exec'ed (e.g. inetd) because the duplicated
listen sockets exist only during the brief interval between the 
fork and the subsequent exec. 
The bug can be reproduced in other packages (e.g. qpopper) 
using forked workers. 

Pierre
 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]