From: ki...@ukr.net To: bug-bash@gnu.org Subject: wait skips signals but first one
Configuration Information [Automatically generated, do not change]: Machine: arm OS: linux-gnueabi Compiler: arm-mydistro-linux-gnueabi-gcc -mthumb -mfpu=neon -mfloat-abi=hard -mcpu=cortex-a7 Compilation CFLAGS: -O2 -pipe -g -feliminate-unused-debug-types -DNON_INTERACTIVE_LOGIN_SHELLS -DHEREDOC_PIPESIZE=65536 -DBRACKETED_PASTE_DEFAULT=0 uname output: Linux mtcap3 5.15.87 #1 PREEMPT Tue Sep 19 16:09:21 UTC 2023 armv7l GNU/Linux Machine Type: arm-mydistro-linux-gnueabi Bash Version: 5.1 Patch Level: 16 Release Status: release Description: I'm working on a custom project within the Yocto framework. After a recent build system update, the bash version updated to 5.1.16. Subsequently, I've noticed peculiar side effects related to using 'wait' and signals. Below is a script demonstrating the issue. The problem lies in the fact that, in the case of waiting on 'wait' in the script, only the first signal interrupts 'wait'; subsequent signals of the same type do not interrupt 'wait', and it remains blocked. I manually switched bash versions and compiled a table (bash version - Yocto version): 5.0.18 (dunfell): No issues 5.1.4 (hardknott): Has issues 5.1.8 (honister): Has issues 5.1.16 (kirkstone): Has issues 5.2.21 (master): Has issues Meanwhile, in my home desktop distribution, Ubuntu 22.04, I tested the same scenario, and everything works correctly; signals are processed as expected. My assumption is that the problem may be related to my Yocto build being intended for a 32-bit device, and perhaps the bug only manifests in this case. I consider this a significant issue. Could you confirm whether any testing has been conducted on 32-bit platforms, as it seems that everything works correctly on 64-bit desktops? Repeat-By: Here is a simple script: #!/bin/bash trap 'echo ">>> TRAPPED HUP <<<"' HUP trap 'echo ">>> TRAPPED USR1 <<<"' USR1 while true; do echo "Iteration" /bin/sleep 15 & wait $! done When I send HUP or USR1 multiple times I see the TRAPPED message only once. strace says: rt_sigprocmask(SIG_BLOCK, [CHLD], [HUP USR1 CHLD], 8) = 0 Meaning that HUP and USR1 remain blocked.