>>>>> "Joe" == Joe Dane <jdane@hawaii.edu> writes:
Joe> I'm encountering what looks like a bug in scsh, and I was hoping I might
get
Joe> some help here in tracking it down.
Joe> It's easy to describe: sometimes scsh forks a subprocess and never comes
Joe> back. In particular, I'm doing a run/string on a program which may or may
Joe> not produce any output. In most cases, things work OK but in a sizable
Joe> fraction (say 10%) scsh appears to hang. The forked process terminates,
but
Joe> scsh never returns. It also does not respond to signals, e.g. Keyboard
Joe> interrupts.
Joe> I have not had much time to dig into this, but I did try sticking a printf
Joe> in the signal handler installed by scsh. When a keyboard interrupt
arrives,
Joe> scsh is getting the signal and printing my message. Also, I put a printf
in
Joe> the loop which calls select() (sorry, don't have the filename handy) and I
Joe> see that the loop continues to run. It looks like it's waiting for an
event
Joe> which never arrives.
Joe> This is on linux 2.4 with an SMP kernel, if that has anything to do with
it.
Joe> Any ideas on where I could look for the problem? Also, it's certainly
Joe> possible that the program being run by scsh is not behaving "correctly"
Joe> somehow, but still ...
There were bugs in earlier versions of scsh which had similar
symptoms. Scsh sometimes missed the SIGCHLD of the dying subprocess
and the current thread would wait forever for a lock to be released by
the signal handler. I spend a long time to make the code as
bullet-proof as I could. With the current version I can not reproduce
your problem at all and fork 5000 subprocesses in a row without.
Does the problem occur for a small program like
(define (f i)
(if (zero? i)
#t
(begin
(run/string (ls))
(f (- i 1)))))
(f 100)
as well or, if not, can you provide a program which triggers the bug?
--
Martin
|