Checking evolution of information about required symbols

2022-10-19 Thread Markus Elfring
Hello,

Some information was published with the subject “Bash-5.2 Release available”
on 2022-09-26.
https://lists.gnu.org/archive/html/bug-bash/2022-09/msg00056.html
https://www.mail-archive.com/info-gnu@gnu.org/msg03096.html

“…
Bash can be linked against an already-installed Readline library rather
than the private version in lib/readline if desired.  Only readline-8.1 and
later versions are able to provide all of the symbols that bash-5.2 requires;
…”

Would you like to recheck and reconsider such information in more detail?

On how many symbols does this program revision depend?

I got the impression that some of them became generally available only with
the change “readline-8.2 distribution sources and documentation” on 2022-09-26.
https://git.savannah.gnu.org/cgit/readline.git/commit/readline.h?id=f7a382fd09319b20ef4435b9b554183b605468c1
https://lists.gnu.org/archive/html/bug-readline/2022-09/msg00010.html
https://www.mail-archive.com/info-gnu@gnu.org/msg03097.html

How do you think about related searches for appropriate solutions?

Examples:
* 2022-10-02
  shells/bash: bash-5.2_2 is marked as broken: ld: error: undefined symbol: 
rl_trim_arg_from_keyseq
  https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=266762

* 2022-10-15
  Fix the availability of the symbol “rl_trim_arg_from_keyseq” (for “bash 
5.2.2”)
  https://bugzilla.opensuse.org/show_bug.cgi?id=1204336

* 2022-10-18
  Checking ABI adjustments once more
  https://lists.gnu.org/archive/html/bug-readline/2022-10/msg00017.html


Regards,
Markus



Exit trap changes return value of subshell for uncaught trap signals

2022-10-19 Thread Andrew Neff via Bug reports for the GNU Bourne Again SHell
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.