Re: [RFC]: Test Were failing on Fedora Linux.

[Jeff King <peff@peff.net>]

On Sat, Nov 09, 2024 at 11:05:55AM -0500, Todd Zullinger wrote:

> The 64-bit libc_malloc_debug.so.0 is in /lib64 and was moved
> to the glibc-utils package in Fedora 40, with 2c1b0f0 (Move
> memory tracing libraries to glibc-utils, 2024-05-15)¹.  The
> commit message notes:
> 
>     On x86_64, glibc-utils will now only contain the 64-bit
>     version of these libraries but still need the 32-bit
>     version (in order to support tracing i686 applications).
>     Therefore, on i686 the libraries remain in the main
>     glibc package.
> 
> If you're interested in installing the various dependencies
> needed to run the test suite on Fedora, take a look at the
> Fedora git package spec file².

Hmm. I wonder if our test scripts could be a little more forgiving here.

The glibc malloc debugging stuff has always been turned on by default
since a731fa916e (Add MALLOC_CHECK_ and MALLOC_PERTURB_ libc env to the
test suite for detecting heap corruption, 2012-09-14). Back then the
setup just involved setting some environment variables. If we were on a
system where it didn't exist, it was no big deal. We'd just run without
it.

That changed in 131b94a10a (test-lib.sh: Use GLIBC_TUNABLES instead of
MALLOC_CHECK_ on glibc >= 2.34, 2022-03-04). Now that glibc split this
out into libc_malloc_debug.so, we have to add it to LD_PRELOAD. We only
do that when we detect glibc, but it sounds like it's possible to have
glibc but not the malloc debug library. In which case we'll produce
errors (at the very least it seems like ld.so will complain to stderr,
which perhaps is the source of the test failures here).

Can we do a better job of detecting that the library is available?

I don't offhand know of a good portable way to ask the system about
available libraries. But I guess just doing something like:

  err=$(LD_PRELOAD=libc_malloc.so.0 git version 2>&1 >/dev/null)
  if test -z "$err"
  then
	...seemed to work...
  fi

would do it? I dunno. Maybe this is not a common enough thing to worry
about. It just seems bad for us to make life harder for people running
the tests for an optional thing.

  Side note: The glibc malloc stuff seems a bit more redundant these
  days, since we run with ASan in CI (which I'd expect to catch a
  superset of what the malloc debugging would). There is some value in
  catching things sooner, though (I don't usually do an ASan run on my
  workstation, and of course some people may not use CI at all).

-Peff