bug-bash
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Chet Ramey
Subject: Re: Using systemd-249's libnss_systemd.so.2 triggers a crash in bash-5.1's malloc.c
Date: Mon, 4 Oct 2021 22:11:10 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.13.0

On 10/4/21 9:44 PM, Dominique Martinet wrote:
Chet Ramey wrote on Mon, Oct 04, 2021 at 09:23:11PM -0400:
   - I could reproduce the same as Julien, with -DDISABLE_MALLOC_WRAPPERS
the crash still happens when bash is run directly but nothing complains
in valgrind.

I assume you mean using systemd. Has anyone tried running a bash linked to
the systemd library that provides the getpw functions, but not as a systemd
unit? You could then run it in a debugger if it crashes, for instance.

I'm running busybox sh in a unit (which starts properly), then
interactively test things from there.

Running in gdb does fail the same way as running normally, so I've also
been looking at that a bit, but nothing obvious poped up.
I'd like to trace back which allocation corresponds to the failing one,
and break from there next time.

Without the allocation tracing, which you don't get from allocations that
aren't directly from bash, it's tedious, but doable. It only works if the
memory layout is consistent enough that you get the same address failing
every time (that is, the address being passed to the failing free() is the
same).

If you do, you write it down, put a breakpoint in internal_malloc at the
point where it returns the memory to its caller, and just run, breaking
at that point, until malloc returns that address. Then run a backtrace and
see where you are.


If you have a nixos system, not necessarily on master, this should be
enough to reproduce:

I don't.

Hm, that won't necessary work with LTO though.
If they call reallocarray, which is in libc, LTO means reallocarray can
call libc's realloc without going through symbol interposition.
(That's a discussion that came up on fedora-devel mailing list when
talking about LTO, and breaking LD_PRELOAD no longer overloading calls
internal to a lib)

Yeah, that would break a whole bunch of things that have worked forever.


--
``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/



reply via email to

[Prev in Thread] Current Thread [Next in Thread]