Christophe Rhodes writes:
> Raymond Wiker <Raymond.Wiker@...> writes:
> > The actual problem appears to be that run-program in some
> > cases is unable to detect that an external program has terminated. In
> > the case of make-target-contrib, the sb-grovel thingy compiles a C
> > program into an executable named "a.out" (funnily enough :-) and runs
> > this. sbcl starts to spin, using ~90% of CPU (the rest taken by "top",
> > in my case), and if I use "ps", I cannot see that "a.out" is running
> > at all.
> > Does this sound familiar to anyone?
> Vaguely familiar, yes, though I've never seen it break during
This seems quite repeatable on my PowerBook (12" AlBook),
MacOSX 10.2.8, although it seems to be a Heisenbug - the operation
> This looks like the same thing as bug #190 from the BUGS file, which
> I've seen on linux/ppc. I've never been able to reproduce it on
> demand or get very far into debugging it, though.
It doesn't seem to be related to buffering between the
subprocess and SBCL - the call from asdf sets up a subprocess to send
it stdout to a file. Could be that it fills up an stderr descriptor,
If it's not a buffering issue, then it may be that the wait3
operation fails. As I said earlier, the process it should be waiting
for is nowhere to be seen. It may also be spinning somewhere else; I
can't see any reason that sbcl should use a lot of cpu in wait3 :-)
> Sorry not to be any more helpful :-/
Helpful enough - at least I know that others have seen a
problem in this area (actually, I saw something about this on the
mailing list earlier, and I *should* have checked BUGS before
Raymond Wiker Mail: Raymond.Wiker@...
Senior Software Engineer Web: http://www.fast.no/
Fast Search & Transfer ASA Phone: +47 23 01 11 60
P.O. Box 1677 Vika Fax: +47 35 54 87 99
NO-0120 Oslo, NORWAY Mob: +47 48 01 11 60
Try FAST Search: http://alltheweb.com/