# [PATCH] test-lib: have SANITIZE=leak imply TEST_NO_MALLOC_CHECK 4 messages from 2022-09-28 to 2022-09-29. Participants: Ævar Arnfjörð Bjarmason, Rubén Justo, Phillip Wood, Junio C Hamano. Thread: https://gitlist.dev/t/58527 ## Ævar Arnfjörð Bjarmason, 2022-09-28 10:01 Subject: [PATCH] test-lib: have SANITIZE=leak imply TEST_NO_MALLOC_CHECK Message-ID: URL: https://gitlist.dev/e/patch-1.1-e31681731b7-20220928T095041Z-avarab%40gmail.com ``` 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). Signed-off-by: Ævar Arnfjörð Bjarmason --- Junio: I think this is worth considering for v2.38.0. We've had this check since v2.36.0 But 2.34 just recently got migrated to Debian testing (just a few days ago), I suspect other distros are either upgrading to it now, or will soon: https://tracker.debian.org/pkg/glibc; When I upgraded to it I discovered that all of our tests pass with SANITIZE=leak, i.e. unless TEST_NO_MALLOC_CHECK=1 is provided we completely disable the LeakSanitizer in favor of glibc. t/test-lib.sh | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/t/test-lib.sh b/t/test-lib.sh index a65df2fd220..02f438d47ec 100644 --- a/t/test-lib.sh +++ b/t/test-lib.sh @@ -563,8 +563,10 @@ case $GIT_TEST_FSYNC in esac # 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" then -- 2.38.0.rc1.925.gb61c5ccd7da ``` ## Rubén Justo, 2022-09-28 23:20 Subject: Re: [PATCH] test-lib: have SANITIZE=leak imply TEST_NO_MALLOC_CHECK Message-ID: <7730c25c-5f10-b1a8-f1c3-cdeaa712ef05@gmail.com> URL: https://gitlist.dev/e/7730c25c-5f10-b1a8-f1c3-cdeaa712ef05%40gmail.com In-Reply-To: ``` On 28/9/22 12:01, Ævar Arnfjörð Bjarmason wrote: > 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). > > Signed-off-by: Ævar Arnfjörð Bjarmason > --- > > Junio: I think this is worth considering for v2.38.0. We've had this > check since v2.36.0 > > But 2.34 just recently got migrated to Debian testing (just a few days > ago), I suspect other distros are either upgrading to it now, or will > soon: https://tracker.debian.org/pkg/glibc; > > When I upgraded to it I discovered that all of our tests pass with > SANITIZE=leak, i.e. unless TEST_NO_MALLOC_CHECK=1 is provided we > completely disable the LeakSanitizer in favor of glibc. > > t/test-lib.sh | 4 +++- > 1 file changed, 3 insertions(+), 1 deletion(-) > > diff --git a/t/test-lib.sh b/t/test-lib.sh > index a65df2fd220..02f438d47ec 100644 > --- a/t/test-lib.sh > +++ b/t/test-lib.sh > @@ -563,8 +563,10 @@ case $GIT_TEST_FSYNC in > esac > > # 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" > then > Thank you! A quick test with this on master shows clearly the leak in ref-filter.c we discussed recently. No need to dig with valgrind. I also found that other case you pointed out, from checkout. I'll reroll with that if you don't mind. It is nice to have this working. Thanks. Un saludo. ``` ## Phillip Wood, 2022-09-29 09:09 Subject: Re: [PATCH] test-lib: have SANITIZE=leak imply TEST_NO_MALLOC_CHECK Message-ID: URL: https://gitlist.dev/e/a013246a-777c-acf8-d2c1-3bf9b78aa9e8%40dunelm.org.uk In-Reply-To: ``` On 28/09/2022 11:01, Ævar Arnfjörð Bjarmason wrote: > 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 > # 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 ``` ## Junio C Hamano, 2022-09-29 15:29 Subject: Re: [PATCH] test-lib: have SANITIZE=leak imply TEST_NO_MALLOC_CHECK Message-ID: URL: https://gitlist.dev/e/xmqqill6p5bq.fsf%40gitster.g In-Reply-To: ``` Phillip Wood writes: > Oh so the LD_PRELOAD breaks both sanitizers but only one of them complains > >> # 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. Thanks, both. Will re-queue with a local fix-up for the indentation. As to the ordering, I usually prefer to have new ones appended to the last unless there are other reasons, and "keep them sorted" is such a reason, so I may do so as well while at it. ```