git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Rubén Justo" <rjusto@gmail.com>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>,
	Git List <git@vger.kernel.org>,
	Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH] test-lib: fix GIT_TEST_SANITIZE_LEAK_LOG
Date: Sat, 6 Jul 2024 13:20:36 +0200	[thread overview]
Message-ID: <75a635b9-7622-42f7-b202-6991775e75f0@gmail.com> (raw)
In-Reply-To: <20240706061850.GB700645@coredump.intra.peff.net>

On Sat, Jul 06, 2024 at 02:18:50AM -0400, Jeff King wrote:
> On Wed, Jul 03, 2024 at 11:44:33PM +0200, Rubén Justo wrote:
> 
> > > Explicitly indicating that the error is being forced due to
> > > "GIT_TEST_SANITIZE_LEAK_LOG=true", for a test that doesn't fail when run
> > > normally or even when run with just
> > > "GIT_TEST_PASSING_SANITIZE_LEAK=yes", could save us some confusion.
> > > 
> > > So, I dunno.
> > > 
> > > Anyway, I agree that this can be addressed later.
> > > 
> > > Thanks.
> > 
> > Maybe what we should do is integrate "GIT_TEST_SANITIZE_LEAK_LOG" into
> > "GIT_TEST_PASSING_SANITIZE_LEAK" because I'm not sure what value we get
> > by keeping them separate (test performance?).  But that's another topic,
> > even further out of scope of this patch :-)
> 
> I don't think we want to integrate them, but I'd suggest that
> SANITIZE_LEAK_LOG should be the default/only option.
> 
> Without it, you are potentially missing leaks in programs whose failing
> exit codes do not trigger a test failure. So there is no point in
> running PASSING_SANITIZE_LEAK=check without also checking the logs. But
> it is still useful to set SANITIZE_LEAK_LOG just for normal runs to look
> for leaks.
> 
> I don't know of any reason we couldn't always check the logs (for a
> leak-checking build), and I didn't see anything in the history. I think
> it was written that way only because there is otherwise no affirmative
> action by the user to say "and btw, look for leaks" (and if we are not
> looking for leaks, there might not be any logs!).
> 
> But really, if you have done a leak-checking build, then every run of
> the tests is looking for leaks, whether you check the logs or not. So we
> should able to just check that $SANITIZE_LEAK is set.

> And then there would be one less thing for people checking for leaks
> to remember to set.

I completely agree.

Let's wait for the dust to settle after the fix in this series, and then
I'll address the change as you described.

Thanks.

  reply	other threads:[~2024-07-06 11:20 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-06-30  6:42 [PATCH] test-lib: fix GIT_TEST_SANITIZE_LEAK_LOG Rubén Justo
2024-07-01  3:49 ` Jeff King
2024-07-01 19:29   ` Junio C Hamano
2024-07-01 20:19 ` Junio C Hamano
2024-07-03 21:35   ` Rubén Justo
2024-07-03 21:44     ` Rubén Justo
2024-07-06  6:18       ` Jeff King
2024-07-06 11:20         ` Rubén Justo [this message]
2024-07-06 23:13           ` Jeff King

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=75a635b9-7622-42f7-b202-6991775e75f0@gmail.com \
    --to=rjusto@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    --cc=sunshine@sunshineco.com \
    /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).