Mail Archives: cygwin/2002/09/16/14:58:47
In message <1032187004 DOT 20821 DOT ezmlm AT cygwin DOT com>,
cygwin-digest-help AT cygwin DOT com writes:
>From: "David A. Cobb" <superbiskit AT cox DOT 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/
- Raw text -