[Libguestfs] [PATCH nbdkit v2 2/2] wrapper: Remove GLIBC_TUNABLES when running under valgrind

Siddhesh Poyarekar sipoyare at redhat.com
Tue Aug 24 11:44:14 UTC 2021

On Tue, Aug 24, 2021 at 2:52 PM Richard W.M. Jones <rjones at redhat.com> wrote:
> There's a problem here ...
> For background see:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/7R3H3RWXC2FEJ6MRTFFUZY5KRYKPL2TQ/
> (You have to click the "..." in that email)
> If libc_malloc_debug.so.0 isn't installed then LD_PRELOAD generates
> lots of warning messages and this actually breaks some tests.
> If ./configure is used without --libdir then we try to set
> LD_PRELOAD=/usr/local/lib/libc_malloc_debug.so.0 which causes the
> warnings/failures.
> My first idea was to test in ./configure if $libdir/libc_malloc_debug.so.0
> exists and only set LD_PRELOAD if so.  However that doesn't work
> because of $!"£% exec_prefix (a.k.a. the most useless GNU feature that
> no one uses but causes all the trouble).
> Also if you have glibc.i686 and glibc.x86_64 installed then both
> /lib64/libc_malloc_debug.so.0 and /lib/libc_malloc_debug.so.0 exist
> and you must choose the correct one.  On other distros the path will
> be different, eg. the 64 bit one in /lib/libc_malloc_debug.so.0 or
> /lib/x86_64-linux-gnu/... etc.

ld.so has a new --list-diagnostics option (since 2.34 AFAICT,
backported to at least 2.33) that lists the system directories; maybe
that could help?

$ /lib64/ld-linux-x86-64.so.2 --list-diagnostics | grep system_dirs

libc_malloc_debug.so.0 will always be in one of these directories
unless a distribution has misconfigured their glibc and not added
their multilib paths into system_dirs.

> So I don't know how to solve any of this.  It would be nicer if glibc
> handled the details and automatically loaded the right library if

It is not impossible to implement; tunable parsing happens early
enough that if any tunable requires a preloaded module then we can
make it happen as long as the module is in path.system_dirs.  We could
fail silently too; it's certainly better than ignoring silently.

Do you see any gotchas here Florian?


More information about the Libguestfs mailing list