git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rubén Justo" <rjusto@gmail.com>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>, git@vger.kernel.org
Cc: Junio C Hamano <gitster@pobox.com>,
	Elia Pinto <gitter.spiros@gmail.com>,
	Phillip Wood <phillip.wood@dunelm.org.uk>
Subject: Re: [PATCH] test-lib: have SANITIZE=leak imply TEST_NO_MALLOC_CHECK
Date: Thu, 29 Sep 2022 01:20:41 +0200	[thread overview]
Message-ID: <7730c25c-5f10-b1a8-f1c3-cdeaa712ef05@gmail.com> (raw)
In-Reply-To: <patch-1.1-e31681731b7-20220928T095041Z-avarab@gmail.com>

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.

  reply	other threads:[~2022-09-28 23:21 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
2022-09-29  9:09 ` Phillip Wood
2022-09-29 15:29   ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7730c25c-5f10-b1a8-f1c3-cdeaa712ef05@gmail.com \
    --to=rjusto@gmail.com \
    --cc=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=gitter.spiros@gmail.com \
    --cc=phillip.wood@dunelm.org.uk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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 NNTP newsgroup(s).