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
