In the meantime I've done some more testing, and I've got a question about how to best fix this.

I've tested cross-compiling for a 32bit armv7 system, instead of the aarch64 system. It shows the same issue (blocking the signals for longer than expected), so it's not aarch64-specific as I thought at first.

Interestingly, with older versions of bash (such as 4.3.39), the issue does not show up, despite them not detecting POSIX sigsetjmp() either. (i.e. they have /* #undef HAVE_POSIX_SIGSETJMP */ but at least my awkward test case still works as expected)
Bisecting pointed to bash 5.1 (git commit 8868edaf) being the first version that changed that.

While of course I can add a local patch to our local Yocto (the distribution we use for cross-compiling), and perhaps even send that to upstream Yocto, it would be much nicer to have a fix in upstream bash.
I don't know whether that's possible though :)

Is this something that can or should be fixed in bash? I understand some configure checks cannot work when cross-compiling, but perhaps there is another solution to this? On the other hand, the sigsetjmp() check is not the only one that cannot work when cross-compiling, so maybe I'm looking at the wrong thing.

Thanks for checking. I am indeed cross-compiling for the aarch64 machine, and config.h does indeed not #define HAVE_POSIX_SIGSETJMP. (configure said "checking for presence of POSIX-style sigsetjmp/siglongjmp... (cached) missing")
Adding that #define fixes the issue.

Before I look at this, this script has several race conditions, not the least of which is that signals are flags, not counters. That is, even if you send several instances of a signal to a process, there is no guarantee that the process will receive more than one. For instance, if the scheduler arranges things so that the `killall' script runs more than once before the first script runs its signal handler, you're going to `lose' signals.

It's also somewhat weird that you're re-instantiating the trap every time through the loop.

I don't have any armv8 systems, but I'll take a look.

Hello,

while using bash 5.1.8 on a 64bit armv8 system, I've encountered an issue with signal handling. The test script sets up a trap for SIGUSR1, then launches a background process (sleep in this case) and uses the "wait" command in a loop to wait for it. If I understood correctly, the "wait" command should return early in case a signal is received, so it can be handled by the trap handler.

When sending signals to this test script while it's running, it appears that only the first signal is received and handled on the aarch64 machine, while on a x86_64 machine it receives and handles all signals.

Test script:

#!/bin/bash
signal=SIGUSR1

on_signal()
{
        echo "trapped $signal"
}
trap on_signal "$signal"

# Start "sleep 5" child process
$(which sleep) 5 &
childpid=$!
echo "started child process"

# Wait for child process to exit, but also handle "wait" returning due to signal.
# "wait" returns immediately with exit code 128+N if signal N is received,
# see section "SIGNALS" in the bash man page.
result=
while [[ -z "$result" || "$result" -gt 128 ]]; do
        trap on_signal "$signal"
        echo "wait"
        wait "$childpid"
        result=$?
        echo "wait returned exit code $result"
done

echo "done"

What I used to send signals to it (run this in parallel to the above test script):

#!/bin/sh
for i in $(seq 1 4); do
        killall -v -SIGUSR1 test.sh
        sleep 1
done

On x86_64, the output is as follows (SIGUSR1 received 4 times, as expected):

started child process
wait
trapped SIGUSR1
wait returned exit code 138
wait
trapped SIGUSR1
wait returned exit code 138
wait
trapped SIGUSR1
wait returned exit code 138
wait
trapped SIGUSR1
wait returned exit code 138
wait
wait returned exit code 0
done

On aarch64, the output is as follows (SIGUSR1 only received once, but should be 4 as on x86_64):

started child process
wait
trapped SIGUSR1
wait returned exit code 138
wait
wait returned exit code 0
done

I've looked at strace output for the bash running the test script, and it seems that on aarch64, it keeps SIGUSR1 blocked after receiving it for the first time:

First wait command, SIGUSR1 is not blocked:

10:25:55.866065 rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0
10:25:55.866108 rt_sigprocmask(SIG_BLOCK, [CHLD], [], 8) = 0
[...]
10:25:55.866208 wait4(-1, 0xffffdf5e10a0, 0, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
10:25:56.627202 --- SIGUSR1 {si_signo=SIGUSR1, si_code=SI_USER, si_pid=532, si_uid=0} ---

Second wait command, SIGUSR1 is/remains blocked:

10:25:56.634380 rt_sigprocmask(SIG_SETMASK, [USR1 CHLD], NULL, 8) = 0
10:25:56.634469 rt_sigprocmask(SIG_BLOCK, [CHLD], [USR1 CHLD], 8) = 0
[...]
10:25:56.634668 wait4(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 0}], 0, NULL) = 528

On x86_64, that does not happen - SIGUSR1 does not remain blocked for the additional wait commands. I've attached the strace logs.

System information:
- The x86_64 machine uses linux 5.13, gcc 11.2, glibc 2.34 (it's Ubuntu 21.10)
- The aarch64 machine uses linux 5.4, gcc 10.2, glibc 2.33 (it's Yocto hardknott on an embedded system)