Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -O2 -flto=auto -ffat-lto-objects -fexceptions -g
-grecord-gcc-switches -pipe -Wall -Werror=format-security
-Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS
-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic
-fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection
uname output: Linux 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2
00:30:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
uname output: Linux 17d50c74abf4 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed
Mar 2 00:30:59 UTC 2022 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu
Environment Bugged: docker run -it --rm bash:5.1
Environment Working: docker run -it --rm bash:5.0
Bash Version: 5.1
Patch Level: 12
Release Status: release
Description:
I discovered an inconsistent bug starting in bash 5.1.12. Setting the
EXIT trap in the grandparent of a subshell that exits via an unset trap signal
causes different return values. If the EXIT trap is unset, the subshell returns
128+signal number (e.g. 138 , for SIGUSR1 (10)). However when the EXIT trap is
set in the grandparent, the subshell returns 0 instead.
Repeat-By:
Run this code in bash 5.1.12 or newer. You’ll see “Error: 138” both
before and after the EXIT signal is set on the older bashes, but not on 5.1.12
or newer.
#!/usr/bin/env bash
set -eu
child_signal()
(
trap "echo you will not see this" USR1
(
kill -USR1 "${BASHPID}"
# echo "Uncomment this to mysteriously fix"
) || echo "Error: ${rv=${?}}"
[ "${rv-0}" != "0" ]
echo
)
echo "No exit trap"
child_signal
echo "Exit trap set"
trap 'echo atexiting...' EXIT
child_signal
echo "The end"
Observed Erroneous Result:
No exit trap
User defined signal 1
Error: 138
Exit trap set
atexiting...
Expected Result (e.g., as in 5.1.11):
No exit trap
User defined signal 1
Error: 138
Exit trap set
User defined signal 1
Error: 138
The end
atexiting...
Fix:
The bug started in the 5.1.12 patch, and it does not happen in 5.1.11.
The bug was still present in the 2022-10-15 devel branch. I am only able to
manifest it with the EXIT signal. I could not reproduce it with other signals
(e.g. “set -T” + the RETURN signal)
One workaround: uncomment the “Uncomment this to mysteriously fix” line
and the bug disappears.
