snapshot 20050114 race (on list)

Christopher Faylor me@cgf.cx
Tue Jan 18 01:38:00 GMT 2005


On Mon, Jan 17, 2005 at 08:30:37PM -0500, Pierre A. Humblet wrote:
>At 02:24 PM 1/16/2005 -0500, Pierre A. Humblet wrote:
>>I have been trying without success to reproduce the race
>>reported by Eric Blake, which started this thread.
>
>I tried again, with the latest cvs, trying to prove that
>"touch" lingers in the directory being removed.
>I still can't reproduce it, but I can get something similar.
>
>Consider:
>C:~: exim 2>/dev/null; ps; ps -W
>      PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
>     2800       1    2800       2800  con 1003 19:26:15 /c/Program
>Files/cygwin/bin/rxvt
>     2632    2800    2632       1448    0 1003 19:26:15 /usr/bin/bash
>     3548    2632    3548       2448    0 1003 20:03:33 /usr/bin/ps
>      PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
>        4       0       0          4    ?    0 15:24:48 *** unknown ***
> <snip>
>     3544       0       0       3544    ?    0 20:03:34
>C:\progra~1\cygwin\bin\exim-4.43-2.exe
>     4044       0       0       4044    ?    0 20:03:34
>C:\progra~1\cygwin\bin\ps.exe
>
>We see that Exim persists as a Windows process long after
>( > two forks and two spawns ) it is gone as a Cygwin process. 
>
>To exhibit the phenomenon reported by Eric, you have to know that exim
>cd's to /var/spool/exim, creating it if needed. Sure enough:
>
>C:~: exim 2>/dev/null; rmdir /var/spool/exim
>rmdir: `/var/spool/exim': Device or resource busy
>C:~: exim 2>/dev/null; rmdir /var/spool/exim
>rmdir: `/var/spool/exim': Device or resource busy
>C:~: exim 2>/dev/null; rmdir /var/spool/exim
>rmdir: `/var/spool/exim': Device or resource busy
>C:~: exim 2>/dev/null; rmdir /var/spool/exim
>rmdir: `/var/spool/exim': Device or resource busy
>C:~: exim 2>/dev/null; sleep 1; rmdir /var/spool/exim
>C:~: exim 2>/dev/null; sleep 1; rmdir /var/spool/exim
>C:~: 
>
>Not sure why exim lingers for so long. Perhaps because it uses many dlls.
>I tried with a few other programs without "success". 
>
>Perhaps removing the alert_parent(0) would alleviate the race, but the
>only safe way is a WaitFor(hProcess). 

You still haven't explained why are there still open handles at the
point where the alert_parent is called.  If that is the case then there
is apparently something wrong in cygwin since all handles are supposed
to be closed at this point.

cgf



More information about the Cygwin-developers mailing list