Bug 1213353

Please also include the current version of libreadline8 as well as of bash via

rpm -qi libreadline8
rpm -qi bash

bash and libreadline8 are from current Tumbleweed. Details:

# rpm -qi libreadline8 bash
Name        : libreadline8
Version     : 8.2
Release     : 2.3
Architecture: x86_64
Install Date: Do 22 Jun 2023 23:48:38 CEST
Group       : System/Libraries
Size        : 446078
License     : GPL-3.0-or-later
Signature   : RSA/SHA512, Mi 14 Jun 2023 17:16:26 CEST, Key ID 35a2f86e29b700a4
Source RPM  : readline-8.2-2.3.src.rpm
Build Date  : Mi 14 Jun 2023 17:13:06 CEST
Build Host  : hurricane3
Packager    : https://bugs.opensuse.org
Vendor      : openSUSE
URL         : https://www.gnu.org/software/readline/
Summary     : The Readline Library
Description :
The readline library is used by the Bourne Again Shell (bash, the
standard command interpreter) for easy editing of command lines.  This
includes history and search functionality.
Distribution: openSUSE Tumbleweed
Name        : bash
Version     : 5.2.15
Release     : 8.4
Architecture: x86_64
Install Date: Do 22 Jun 2023 23:48:49 CEST
Group       : System/Shells
Size        : 1094000
License     : GPL-3.0-or-later
Signature   : RSA/SHA512, Mi 14 Jun 2023 20:53:06 CEST, Key ID 35a2f86e29b700a4
Source RPM  : bash-5.2.15-8.4.src.rpm
Build Date  : Mi 14 Jun 2023 20:43:18 CEST
Build Host  : lamb59
Packager    : https://bugs.opensuse.org
Vendor      : openSUSE
URL         : https://www.gnu.org/software/bash/bash.html
Summary     : The GNU Bourne-Again Shell
Description :
Bash is an sh-compatible command interpreter that executes commands
read from standard input or from a file.  Bash incorporates useful
features from the Korn and C shells (ksh and csh).  Bash is intended to
be a conformant implementation of the IEEE Posix Shell and Tools
specification (IEEE Working Group 1003.2).
Distribution: openSUSE Tumbleweed

Just to be sure ... you have installed bash-completion as well ... do you have something in path which is named `systemct` (not `systemctl`) ... shell function, further command, or an alias?

The other problem is that I do not have a glibc-debuginfo-2.37-4.4.x86_64 anymore around to see the specific malloc_printerr()

Also I'd lik eto see your prompts PS0, PS1, PS2, PS3, and PS4

The crash is caused by abort called via malloc_printerr() here in  malloc_consolidate() of glibc-2.37/malloc/malloc.c

      do {
        {
          if (__glibc_unlikely (misaligned_chunk (p)))
            malloc_printerr ("malloc_consolidate(): "
                             "unaligned fastbin chunk detected");

          unsigned int idx = fastbin_index (chunksize (p));
          if ((&fastbin (av, idx)) != fb)
            malloc_printerr ("malloc_consolidate(): invalid chunk size");
        }

and as

 static void
 malloc_printerr (const char *str)
 {
 #if IS_IN (libc)
   __libc_message ("%s\n", str);
 #else
   __libc_fatal (str);
 #endif
   __builtin_unreachable ();
 }

both __libc_message() and __libc_fatal() (via __libc_message()) call abort() ... AFAICS glibc-2.37/sysdeps/posix/libc_fatal.c

...note sure if this is a bash/libreadline problem here.

Which means you have a memory corruption.

(In reply to Andreas Schwab from comment #8)
> Which means you have a memory corruption.

OK ... that is what we already know ... the real reason/cause would be a win.
Error in bash/libreadline ... or in (g)libc ... or overheated system

That *is* the real reason.

(In reply to Andreas Schwab from comment #10)
> That *is* the real reason.

OK means glibc stumble over 2608 bytes

(gdb) down
#9  0x000055ff5a69fd61 in vlist_alloc (nentries=325) at /usr/src/debug/bash-5.2/variables.c:4172
4172      vlist->list = (SHELL_VAR **)xmalloc ((nentries + 1) * sizeof (SHELL_VAR *));
(gdb) print (nentries + 1) * sizeof (SHELL_VAR *)
$2 = 2608
(gdb) down
#8  0x000055ff5a6938ee in xmalloc (bytes=2608) at /usr/src/debug/bash-5.2/xmalloc.c:114
114       temp = malloc (bytes);
(gdb) print bytes
$3 = 2608
(gdb) down
#7  0x00007fe721790aba in malloc () from /lib64/libc.so.6
(gdb) down
#6  0x00007fe72178f6b8 in _int_malloc () from /lib64/libc.so.6
(gdb) down
#5  0x00007fe72178d03c in malloc_consolidate () from /lib64/libc.so.6
(gdb) down
#4  0x00007fe72178c417 in malloc_printerr () from /lib64/libc.so.6
(gdb) down
#3  0x00007fe721719611 in __libc_message.cold () from /lib64/libc.so.6
(gdb) down
#2  0x00007fe721718921 in abort () from /lib64/libc.so.6

I'm not going to debug your program.

(In reply to Andreas Schwab from comment #12)
> I'm not going to debug your program.

IMHO bash does nothing wrong with its list used for completion

      if (varlist)
        free (varlist);

      varlist = all_visible_functions ();

the only thing which could trigger anything is that there is beside systemctl also a systemct in ~/bin/ .. and ~/bin/ is listed several times in PATH but
even with this I can not trigger an abort().

#13 0x000055ff5a68dc6a in command_word_completion_function (hint_text=0x55ff5c85cd30 "systemct", state=0) at /usr/src/debug/bash-5.2/bashline.c:2099
        temp = <optimized out>
        cval = <optimized out>
        inner = <optimized out>
        dequoted_hint = 0x55ff5c7de7d0 "\360:\202\\\377U"
        hint = 0x55ff5c7de7d0 "\360:\202\\\377U"
        searching_path = 0
        mapping_over = 0
        hint_is_dir = 0
        val = 0x0
        igncase = 0
        old_glob_ignore_case = 0
        glob_matches = 0x0
        globpat = 0
        directory_part = 0x0
        hint_len = 8
        filename_hint = 0x55ff5c6baee0 "/home/cb/bin/systemct"
        fnhint = 0x55ff5c6baee0 "/home/cb/bin/systemct"
        istate = 0
        path = 0x55ff5c6090d0 "/home/cb/bin:/usr/local/bin:/usr/bin:/bin:/home/cb/bin:/home/cb/bin"
        path_index = 0
        local_index = 0
        varlist = 0x55ff5c859150
        alias_list = 0x55ff5c933e50

(In reply to Dr. Werner Fink from comment #5)
> Just to be sure ... you have installed bash-completion as well ... 

Right, bash-completion-2.11-7.1.noarch

> do you
> have something in path which is named `systemct` (not `systemctl`) ... shell
> function, further command, or an alias?

No,   systemc<tab>   only results in   systemctl   (for both user and root)

(In reply to Dr. Werner Fink from comment #6)
> Also I'd lik eto see your prompts PS0, PS1, PS2, PS3, and PS4

cb@tux:~> echo $PS0

cb@tux:~> echo $PS1
\u\[\e[0m\]@\h:\[\e[1;37;44m\]\w\[\033[0;0m\]>
cb@tux:~> echo $PS2
>
cb@tux:~> echo $PS3

cb@tux:~> echo $PS4
+

I also have a PROMPT_COMMAND:

cb@tux:~> echo $PROMPT_COMMAND
setLastCommandState;setGitPrompt

which is from git@github.com:cboltz/bash-git-prompt.git (actually a version from 2019, 148d502b666a0d62ecc83680817596b097a70f2a)

(In reply to Dr. Werner Fink from comment #9)
> OK ... that is what we already know ... the real reason/cause would be a win.
> Error in bash/libreadline ... or in (g)libc ... or overheated system

Given the hot weather in the last days, I wouldn't rule out overheated system. However, this was the only strange issue I noticed during these hot days.

(In reply to Christian Boltz from comment #14)

> (In reply to Dr. Werner Fink from comment #9)
> > OK ... that is what we already know ... the real reason/cause would be a win.
> > Error in bash/libreadline ... or in (g)libc ... or overheated system
> 
> Given the hot weather in the last days, I wouldn't rule out overheated
> system. However, this was the only strange issue I noticed during these hot
> days.

If the autocomplete of the bash/libreadline is the reason the dump is not that useful as the abort() of the glibc had detected an error which had already happen (IMHO) and in the dump the backtrace (even with full option) shows an other action which belongs to the executable systemct below /home/cb/bin/ ... note the missing `l' to get a complete systemctl located in /usr/bin/

In bash mailing list Grisha Levit had found via AddressSanitizer of the gcc some bug e.g. in parse.y but this was for current devel version not bash 5.2 ... nevertheless the e.g. the use-after-free of ttok is also in 5.2 AFAICS

Created attachment 868317 [details]
bash-asan.tar.xz

A version of bash and libreadline compiled and linked wit address sanitizer ... warning could be dangerous

 tar tf bash-asan.tar.xz
 bin/bash.asan
 lib64/bash/libhistory.so.8
 lib64/bash/libhistory.so.8.2
 lib64/bash/libreadline.so.8
 lib64/bash/libreadline.so.8.2

here it works in a chroot environent ...

 noether:~ # mount -t proc proc /abuild/oscbuild/standard/proc
 noether:~ # chroot /abuild/oscbuild/standard/ /bin/bash.asan
 noether:/ # ll /proc/$$/exe 
 lrwxrwxrwx 1 root root 0 Jul 19 12:42 /proc/11752/exe -> /usr/bin/bash.asan
 noether:/ # exit
 noether:~ # umount /abuild/oscbuild/standard/proc

... the problem could be libreadline which might also poison /bin/bash via runtime linker

Just tried a local user cb here with your prompt as well as a systemct in ~/bin/ ... the Asan only reports some smaller leaks nothing to worry about ... the git prompt shell functions seems to scan the a git repository (I'm using a local clone git@github.com:cboltz/bash-git-prompt.git) ... no corrupted memory

AFAICS from source code those two leaks are false positive as there are checks if the allocated strings/character arrays are already allocated

(In reply to Dr. Werner Fink from comment #17)
> Just tried a local user cb here with your prompt as well as a systemct in
> ~/bin/ .

Just to clarify:

cb@tux:~> ls -l ~/bin/syst*
ls: cannot access '/home/cb/bin/syst*': No such file or directory

I don't have a "systemct" binary - not in ~/bin/, and also not somewhere else in $PATH. (Also no function or alias with that name.)

Created attachment 868418 [details]
bash-asan.tar.xz ... with disables leak check and

Please try this one ... install below root aka / via

  cd /
  tar xf /<pathto>/bash-asan.tar.xz

edit /etc/passwd to use /bin/bash.asan for user cb.

Content:

 tar tf /usr/src/werner/bash/bash/bash-asan.tar.xz 
 usr/bin/bash.asan
 usr/lib64/libhistory_asan.so
 usr/lib64/libhistory_asan.so.8
 usr/lib64/libhistory_asan.so.8.2
 usr/lib64/libreadline_asan.so
 usr/lib64/libreadline_asan.so.8
 usr/lib64/libreadline_asan.so.8.2

note that /bin should be a link to /usr/bin

Any news here?

The good news is that I never had bash crashing since then.

The "bad" news is that this means that single crash will stay a mystery - with no way to reproduce it, finding out what happened is more or less impossible. On the positive side, let's assume it really was a one-time issue and hopefully won't happen again.

To sum it up: feel free to close as "worksforme" ;-)

OK