Re: Using systemd-249's libnss_systemd.so.2 triggers a crash in bash-5.1's malloc.c

[Chet Ramey]

On 10/4/21 10:17 AM, Andreas Schwab wrote:
> On Okt 04 2021, Chet Ramey wrote:
> 
>> On 10/4/21 4:34 AM, Andreas Schwab wrote:
>>> On Okt 04 2021, Julien Moutinho wrote:
>>>
>>>> - bash crashes inside valgrind too,
>>>>   but apparently something different is happening
>>>>   because it crashes even without systemd being involved:
>>>>
>>>> $ nix build .#bash5-with-bash-malloc
>>>> $ valgrind result/bin/bash --norc -c true
>>>>> ==307088== Memcheck, a memory error detector
>>>>> ==307088== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
>>>>> ==307088== Using Valgrind-3.16.1 and LibVEX; rerun with -h for copyright 
>>>>> info
>>>>> ==307088== Command: result/bin/bash --norc -c true
>>>>> ==307088== 
>>>>> ==307088== Invalid free() / delete / delete[] / realloc()
>>>>> ==307088==    at 0x483F8E9: free (in 
>>>>> /nix/store/7s7hzqaf5imxmpjlxh2n6fs7ixml98ya-valgrind-3.16.1/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>>>>> ==307088==    by 0x47330F: xfree (xmalloc.c:150)
>>>>> ==307088==    by 0x4644FA: unwind_frame_run_internal (unwind_prot.c:325)
>>>>> ==307088==    by 0x4640B6: without_interrupts (unwind_prot.c:117)
>>>>> ==307088==    by 0x464656: run_unwind_frame (unwind_prot.c:143)
>>>>> ==307088==    by 0x479ACA: parse_and_execute (evalstring.c:523)
>>>>> ==307088==    by 0x41C0A5: run_one_command (shell.c:1440)
>>>>> ==307088==    by 0x41D6A1: main (shell.c:741)
>>>>> ==307088==  Address 0x404be10 is in the brk data segment 
>>>>> 0x4033000-0x4054fff
>>>
>>> Here is a patch:
>>
>> How does this fix the problem with valgrind? How does wrapping xfree in a
>> local function help?
> 
> Because xfree is a function-like macro, so taking the address does not
> work.

Nope, I don't buy that as the reason. xfree (name of function) and xfree(x)
(macro defined in xmalloc.h) are not the same thing. Unless you mean that
the existence of the macro confuses valgrind? Or something else?

Indeed, when you step through the code in a debugger, breaking at the spot
in parse_prologue that installs the unwind-protect, you see:

(gdb) b evalstring.c:257
Breakpoint 1 at 0x48d1b5: file
/usr/homes/chet/src/bash/src/builtins/evalstring.c, line 257.
(gdb) r -c 'echo a'
Starting program:
/mnt/src-build/build/linux/chet/bash/bash-current.rhe7/bash -c 'echo a'

Breakpoint 1, parse_prologue (string=0x7c6150 "echo a", flags=20,
    tag=0x4f4c33 "parse_and_execute top")
    at /usr/homes/chet/src/bash/src/builtins/evalstring.c:257
257         add_unwind_protect (xfree, orig_string);
Missing separate debuginfos, use: debuginfo-install
glibc-2.17-324.el7_9.x86_64 ncurses-libs-5.9-14.20130511.el7_4.x86_64
(gdb) p orig_string
$1 = 0x7c6150 "echo a"
(gdb) s
add_unwind_protect (cleanup=0x486220 <xfree>, arg=0x7c6150 "echo a")
    at /usr/homes/chet/src/bash/src/unwind_prot.c:152
152       without_interrupts (add_unwind_protect_internal, (char *)cleanup, 
arg);

and everything works correctly.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/