This is the mail archive of the
cygwin-developers@cygwin.com
mailing list for the Cygwin project.
Re: snapshot 20050114 race (on list)
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