signal after the first delivery. It also double-fires signals under some
circumstances. This patch fixes the first of those issues. I don't have a fix for the second issue (and not sure if I'll have time to chase that one down, since it's not actually breaking things in our environment).
Basically what happens is that when a signal gets delivered, the kernel
automatically blocks any further deliveries of that same signal until the
signal handler returns, or the signal mask is explicitly changed. In busybox,
the signal handler longjmp's to elsewhere. As such, the signal mask keeps getting added to as signals come in, and stuff breaks more and more. This isn't
immediately obvious, since the behaviour only appears for busybox built-in
commands. Commonly things are either executed in a subshell (which then has the
damage confined to that subshell), or external commands (which don't have this
issue).
To reproduce, simply run "./busybox ash" (assuming it's built with ash included of course) and run this sequence:
sleep 10 &
wait
^C
wait
(this might return right away due to the last ^C getting re-fired - bug 2)
wait
^C
As you'll notice, the last ^C has no effect at all, due to SIGINT being blocked after the first ^C was pressed. With the attached patch, it behaves as expected. The instant return of the second "wait" is still present however.
I've run the test case on a 1.1.3 system too, and it too has the same bug.
sigmask.patch [^] (367 bytes) 03-20-07 22:42 
