On Sat, Nov 9, 2024 at 2:00 PM Jeff King <peff@xxxxxxxx> wrote: > > 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). > Hi Peff, This is definitely a good suggestion. I think at atleast we should have this stated in INSTALL instructions. What do you think ? Usman > -Peff
