Curious behavior of CYGSERVER/rm infinite loop

[John P. Rouillard]

In message <1032187004.20821.ezmlm@cygwin.com>,
cygwin-digest-help@cygwin.com writes:
>From: "David A. Cobb" <superbiskit@cox.net>
... 

>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
can.

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?

				-- rouilj
John Rouillard
===============================================================================
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
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/