On 4/12/11 8:33 AM, Roman Rakus wrote:
> There's a race condition when you can hit following:
> set_signal_handler (sig, SIG_IGN);
> change_signal (sig, savestring (string));
> set_signal_handler (sig, trap_handler);
> in trap.c file, set_signal() function.
> So bash set signal to be ignored and then set it to be handled by
> trap_handler. However how should bash behave when the signal is received
> when the trap_handler has been set before. Check the following reproducer:
[...]
> You can send SIGUSR1 to bash running traploop.sh in the state, when the
> signal is ignored, but shouldn't be. Is there any reason why is the signal
> for short time ignored?
Probably because it's very old code. That has been there essentially
unchanged since at least bash-1.12 -- almost twenty years ago. It would
be better to block the signal while the trap string and handler are
being modified.
Chet
>
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU c...@case.edu http://cnswww.cns.cwru.edu/~chet/
