Re: [PATCH] test-lib: have SANITIZE=leak imply TEST_NO_MALLOC_CHECK
- From
- Phillip Wood <phillip.wood123@gmail.com>
- Date
- Sep 29, 2022, 09:09 UTC
- Message-ID
- <a013246a-777c-acf8-d2c1-3bf9b78aa9e8@dunelm.org.uk>
- In-Reply-To
- <patch-1.1-e31681731b7-20220928T095041Z-avarab@gmail.com>
On 28/09/2022 11:01, Ævar Arnfjörð Bjarmason wrote:
Show 18 quoted lines
> Since 131b94a10a7 (test-lib.sh: Use GLIBC_TUNABLES instead of > MALLOC_CHECK_ on glibc >= 2.34, 2022-03-04) compiling with > SANITIZE=leak has missed reporting some leaks. The old MALLOC_CHECK > method used before glibc 2.34 seems to have been (mostly?) compatible > with it, but after 131b94a10a7 e.g. running: > > TEST_NO_MALLOC_CHECK=1 make SANITIZE=leak test T=t6437-submodule-merge.sh > > Would report a leak in builtin/commit.c, but this would not: > > TEST_NO_MALLOC_CHECK= make SANITIZE=leak test T=t6437-submodule-merge.sh > > Since the interaction is clearly breaking the SANITIZE=leak mode, > let's mark them as explicitly incompatible. > > A related regression for SANITIZE=address was fixed in > 067109a5e7d (tests: make SANITIZE=address imply TEST_NO_MALLOC_CHECK, > 2022-04-09).
Oh so the LD_PRELOAD breaks both sanitizers but only one of them complains
Show 8 quoted lines
> # Add libc MALLOC and MALLOC_PERTURB test only if we are not executing > -# the test with valgrind and have not compiled with SANITIZE=address. > +# the test with valgrind and have not compiled with conflict SANITIZE > +# options. > if test -n "$valgrind" || > + test -n "$SANITIZE_LEAK" || > test -n "$SANITIZE_ADDRESS" || > test -n "$TEST_NO_MALLOC_CHECK"
The indentation is dodgy, also it would be nice to keep these in alphabetical order. Other than that this looks like a sensible fix.
Best Wishes
Phillip