Christophe Rhodes <csr21@...> writes:
> "Leslie P. Polzer" <sky@...> writes:
>> Further amended the test case.
> +(with-test (:name (:run-program :inherit-stdin))
> + (assert
> + (let (stopped)
> + (flet ((status-hook (proc)
> + (ecase (sb-ext:process-status proc)
> Is this test case actually working for you? It isn't for me. The
> reason, I think, is that when you process-kill with sigterm, that causes
> a status change, which isn't one of the magic four signals and hence
> gives :signalled, not :stopped; then status-hook is called, giving an
> At least, that's my diagnosis. But since the reason I myself was
> reluctant to merge this was because I didn't understand it, I would like
> confirmation from wiser heads. If this test case as stands (which is in
> CVS HEAD, incidentally) runs for everyone else, maybe because everyone's
> hardware is much more spiffy than mine and only I am vulnerable to a
> race condition, then fine. (But it seems wrong to me.)
After some discussion with people who are awake at this point in the day
on #lisp IRC, I convinced myself of two things:
* it is a race condition: if the ed(1) process is terminated by the
SIGTERM before the SIGCHLD handler in sbcl runs, then waitpid() fails
and the process is deleted from *active-processes*, under which
conditions the status-changed hook in the test is never run. My guess
is that this happens commonly on multiprocessors; on my uniprocessor
with non-threaded SBCL, the run-program test for inherited stdin
failed apparently deterministically.
* no-one much seems to be testing anything much during the freeze
period. (I can't really believe that I'm the only one with this
particular failure mode; also, the last-minute testing that I coerced
from victims on IRC suggest that there are regressions or at least
unexpected test failures on FreeBSD).
Consequently, I have released sbcl-1.0.32. Go forth and destabilize.