This is the mail archive of the
mailing list for the Cygwin project.
Re: Curious behavior of CYGSERVER/rm infinite loop
- From: "John P. Rouillard" <rouilj at cs dot umb dot edu>
- To: cygwin at cygwin dot com
- Date: Mon, 16 Sep 2002 14:58:36 -0400
- Subject: Re: Curious behavior of CYGSERVER/rm infinite loop
- Reply-to: rouilj at ieee dot org
In message <firstname.lastname@example.org>,
>From: "David A. Cobb" <email@example.com>
>It varies! One thing, however, that is pretty consistant: when
>configure freezes up, the "active" process is rm.exe, spawned by
>sh.exe. This even happened once when a parameter error caused the
>configure script to fail; assuming that happened within maybe
>10-minutes, the rm.exe hung around for 3-hours while I went away and
>came back. Then I did something really strange: I fired off a second
>terminal session and ran gdb, attaching to the rm.exe process. The
>EIP is way up in Microsoft land: 0x77f9f9e0.
>Now, I don't know whether pids get reused that quickly! But this
>looks like a classical deadly embrace. The same sort of suggestion
>comes from watching rm.exe's handles from ProcessExplorer. When it's
>stuck it keeps activating and then killing handles on one single
>/tmp/ directory. It seems it is trying to get control of some
>resource, being denied, and not quite knowing what to do. As in
>retrying when the status != EAGAIN(?)
Could this be the result of an rm of an open file?
Under windows, you can't remove an open file. Under Unix/Posix you
If rm tries to remove a directory with an open file in it, it will
fail leading to an infinite loop (reported elsewhere in the archives).
I am not sure how/when/if the loop is broken. Maybe having cygserver
running perturbs the timing slightly and allows the rm to succeed by
having the file closed before the first rm attempt?
My employers don't acknowledge my existence much less my opinions.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html