* [PATCH] test-lib: have SANITIZE=leak imply TEST_NO_MALLOC_CHECK
@ 2022-09-28 10:01 Ævar Arnfjörð Bjarmason
2022-09-28 23:20 ` Rubén Justo
2022-09-29 9:09 ` Phillip Wood
0 siblings, 2 replies; 4+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2022-09-28 10:01 UTC (permalink / raw)
To: git
Cc: Junio C Hamano, Elia Pinto, Phillip Wood,
Ævar Arnfjörð Bjarmason
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 <avarab@gmail.com>
---
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
^ permalink raw reply related [flat|nested] 4+ messages in thread
* Re: [PATCH] test-lib: have SANITIZE=leak imply TEST_NO_MALLOC_CHECK
2022-09-28 10:01 [PATCH] test-lib: have SANITIZE=leak imply TEST_NO_MALLOC_CHECK Ævar Arnfjörð Bjarmason
@ 2022-09-28 23:20 ` Rubén Justo
2022-09-29 9:09 ` Phillip Wood
1 sibling, 0 replies; 4+ messages in thread
From: Rubén Justo @ 2022-09-28 23:20 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason, git
Cc: Junio C Hamano, Elia Pinto, Phillip Wood
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 <avarab@gmail.com>
> ---
>
> 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] test-lib: have SANITIZE=leak imply TEST_NO_MALLOC_CHECK
2022-09-28 10:01 [PATCH] test-lib: have SANITIZE=leak imply TEST_NO_MALLOC_CHECK Ævar Arnfjörð Bjarmason
2022-09-28 23:20 ` Rubén Justo
@ 2022-09-29 9:09 ` Phillip Wood
2022-09-29 15:29 ` Junio C Hamano
1 sibling, 1 reply; 4+ messages in thread
From: Phillip Wood @ 2022-09-29 9:09 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason, git; +Cc: Junio C Hamano, Elia Pinto
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [PATCH] test-lib: have SANITIZE=leak imply TEST_NO_MALLOC_CHECK
2022-09-29 9:09 ` Phillip Wood
@ 2022-09-29 15:29 ` Junio C Hamano
0 siblings, 0 replies; 4+ messages in thread
From: Junio C Hamano @ 2022-09-29 15:29 UTC (permalink / raw)
To: Phillip Wood; +Cc: Ævar Arnfjörð Bjarmason, git, Elia Pinto
Phillip Wood <phillip.wood123@gmail.com> 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.
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2022-09-29 15:30 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-28 10:01 [PATCH] test-lib: have SANITIZE=leak imply TEST_NO_MALLOC_CHECK Ævar Arnfjörð Bjarmason
2022-09-28 23:20 ` Rubén Justo
2022-09-29 9:09 ` Phillip Wood
2022-09-29 15:29 ` Junio C Hamano
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).