turns out there WAS something fishy in signal handling in the "generic"

reaper. Specifically, the sigprocmask/wait/sigsuspend dance is correct for
the main process, BUT you have to remember to reset the signal mask to
something sane for the child (this was a duh! moment, that bug is very
stupid)


Finally, bluhm@  saw the actual issue. Kudoes to him.

The change to "unify" sequential and parallel make  made the bug reproducible
under some circumstances
(because in the parallel make case, many things may happen in different
successions, so you don't get the wrong signal mask that often, but the
sequential case is reproducible, and using the "streamlined" reaper meant the
fork would occur WITHIN the signal loop instead of OUTSIDE)

So:
- discover signal state early on through Sigset_init;
- introduce reset_signal_mask to get back to the initial state;
- call reset_signal_mask systematically after fork

This organisation thanks to cmd_exec.  SOME cmd_exec happens before Job_Init
happens, some afterwards (variables are still lazy and both !!= and :sh will
occur AFTER parsing), so both fork() need to be protected.

okay bluhm@

thx to sthen@ and naddy@ and mpi@ for helping out.

0 files changed, 0 insertions, 0 deletions