Re[2]: wait skips signals but first one

[Mykyta Dorokhin]

Hello,

Again, I'm on ("commit bash-20200221 snapshot") commit, the one I  think breaks 
things:

https://git.savannah.gnu.org/cgit/bash.git/commit/?h=devel&id=0df4ddca3f371bc258fe4185cdec36fce3e7be7b

There is a line in trap.c with your change. If I revert it then everything 
works again:

- if (interrupt_immediately && wait_intr_flag)
+ if (/* interrupt_immediately && */wait_intr_flag)

So if I put interrupt_immediately back and rebuild the code with thes only fix 
then it starts working properly, signals are getting received as expected.

Can you comment? Maybe you want me to provide some additional debug info?

Thank you,
Mykyta




3 февраля 2024, 22:09:33, от "Chet Ramey" <chet.ramey@case.edu>:

On 2/3/24 10:00 AM, Mykyta Dorokhin wrote:

> I have found the commit on devel branch which breaks things for me (and 
> probably other Yocto-based builds):
> 
> This one still works
> ======================
> 
> commit 89d788fb0152724a93e0fdab8c15116e5c76572b
> Author: Chet Ramey <chet.ramey@case.edu>
> Date:   Mon Feb 17 11:41:35 2020 -0500
> 
>     commit bash-20200214 snapshot
> 
> This one not
> ======================
> 
> 
> commit 0df4ddca3f371bc258fe4185cdec36fce3e7be7b
> Author: Chet Ramey <chet.ramey@case.edu>
> Date:   Mon Feb 24 10:41:37 2020 -0500
> 
>     commit bash-20200221 snapshot
> 
> 
> 
> Please take a look. Maybe you'll notice something suspicious there. I don't 
> know... uninitialized variables, endian-dependent code, etc.

There are changes there, of course, but it's hard to see how they make a
difference. The wait builtin was changed not to interrupt the wait for a
trapped SIGCHLD, but to delay running any SIGCHLD trap until the wait
exited. Since your example doesn't trap SIGCHLD, it doesn't seem
significant. Any other trapped signal still interrupts the wait. Subshells
clear the process substitution FIFO list, but you're not using process
substitution.

The one change that might make a difference is a bug fix: if the wait
builtin is waiting for a process and receives a trapped signal, it's
supposed to cause wait to return immediately and then run the trap. Bash
didn't do that consistently for SIGINT, and would run the trap when it
shouldn't, or before it should, and sometimes not return from the wait
at all. So maybe the longjmp back to the wait builtin is what changed
things, even though longjmp is one of the functions that POSIX says is
safe to call from a signal handler context, and it restores the signal
mask if you're running on a system that has sigsetjmp/siglongjmp.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/