mainThe GNU Bourne-Again SHell - Support: sr #110697, a rare usage pattern


sr #110697: a rare usage pattern

Submitter:  Jose E <jose_e>
Submitted:  Thu 18 Aug 2022 07:29:05 PM UTC
Category:  None Priority:  5 - Normal
Severity:  3 - Normal Status:  Need Info
Privacy:  Public Assigned to:  None
Open/Closed:  Open Operating System:  GNU/Linux
* Mandatory Fields

Add a New Comment Rich Markup

Wed 28 Sep 2022 02:56:05 PM UTC, comment #2: 

Sorry, I've never been able to reproduce this.

Chet Ramey <chet>
Group administrator
Thu 18 Aug 2022 07:33:11 PM UTC, comment #1: 

Very sorry for the above sparse report

Jose E <jose_e>
Thu 18 Aug 2022 07:29:05 PM UTC, original submission:  

Configuration Information [Automatically generated, do not change]:
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 obfuscated 5.18.6-200.fc36.x86_64 #1 SMP PREEMPT_DYNAMIC Wed Jun 22 13:46:18 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
Machine Type: x86_64-redhat-linux-gnu

Bash Version: 5.1
Patch Level: 16
Release Status: release


(We are very sorry for this sparse report below. This has happened a very few times (4 or 5), it is a very rare usage pattern, and we can't reproduce it in a black-box analysis. Perhaps more information is gained if the MALLOC_CHECK_ environment variable is set at the beginning before the execution of the interactive session, we don't know, instructions would be helpful.)

A shell interactive session (process) invokes sequentially several programs of the form:

$  'some_cmd_line_argument'  $( grep -l 'regexp'  set_of_files )

where "" doesn't need to be the same, nor
'some_cmd_line_argument', 'regexp', "set_of_files", which can differ among different invocations (sometimes "set_of_files" can be a glob, "*.<extension>"). (There could also be other programs invoked among the above sequence of instructions, like "echo '...' | logger ...", "ls -l | logger ...", etc.)

At some point, the invocation starts giving:

     free(): invalid next size (fast)
     Aborted (core dumped)


     $ echo $?

(Usually "echo $?" returns 0.)

systemd-coredump is not actually saving the core dumps.

(The above message and core seems happening after execution of:

  $ 'some_cmd_line_argument' $( grep -l 'regexp'  set_of_files )

There is a gdb file attached, "gdb -p <pid-interactive-session-with-this-issue>"). One thing of notice that seems to appear in common among some gdbs (when summarized from some gdb files of different interactive sessions with the current issue) is that the last child-process stack (the child process for "" itself, not the child for "$( grep -l 'regexp'  set_of_files )") shows:

1. In frame 8, dispose_variable(), it seems to be always at "free (var->name);" where var->name is "PS2" and var->value doesn't seem to be '> ' that is the value of PS2:

    $ set | grep PS2
    PS2='> '

(gdb) frame 8
     #8  0x0000555bb4bf0f5e in dispose_variable (var=0x555bb643d5c0) at /usr/src/debug/bash-5.1.16-2.fc36.x86_64/variables.c:3780
     3780      free (var->name);
(gdb) p *var
     $1 = {name = 0x555bb6439f90 "PS2", value = 0x555bb643be40 "+\342\370\343^U", exportstr = 0x0, dynamic_value = 0x0, assign_func = 0x0, attributes = 0, context = 0}
(gdb) print var->name
     $3 = 0x55f6b514bf90 "PS2"
(gdb) print var->value
     $4 = 0x55f6b514de40 "]\367\177\352\363U"

2. In frame 10, hash_flush(), bucket is NULL, so this is the last iteration of the "while (bucket)" loop:

(gdb) frame 10
     #10 hash_flush (free_data=<optimized out>, table=<optimized out>) at /usr/src/debug/bash-5.1.16-2.fc36.x86_64/hashlib.c:395
     395                 (*free_data) (item->data);
(gdb) info locals
     i = 824
     bucket = 0x0
     item = 0x555bb643a280
(gdb) p *item
     $2 = {next = 0x0, key = 0x555bb643bd60 "PS2", data = 0x555bb643d5c0, khash = 472346424, times_found = 4338}

Unfortunately, it doesn't seem easy to reproduce the cause of this issue by replaying in a black-box analysis the previous history till occurrence of the first:
              free(): invalid next size (fast)
              Aborted (core dumped)
because in:

$  'some_cmd_line_argument'  $( grep -l 'regexp'  set_of_files )

"" can modify the contents of the files, so that the  $( grep -l 'regexp'  set_of_files ) can give a different result after running "". (I.e., "" is not idem-potent.) We have tried to reproduce with test idem-potent scripts like an " ..." whose content is "echo  $@;  /bin/echo  $@", but, the above message hasn't been reproduced.

Jose E <jose_e>


(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:

Attached Files
file #53580:  a_gdb_session.txt added by jose_e (4KiB - text/plain)


Depends on the following items: None found

Items that depend on this one: None found


Carbon-Copy List
  • -email is unavailable- added by chet (Posted a comment)
  • -email is unavailable- added by jose_e (Submitted the item)

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.


    Follow 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-09-28 chet StatusNone Need Info
    2022-08-18 jose_e Attached File- Added a_gdb_session.txt, #53580

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code