From: Jeff King <peff@peff.net>
To: "Rubén Justo" <rjusto@gmail.com>
Cc: "Git List" <git@vger.kernel.org>,
"Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Subject: Re: [PATCH 2/2] test-lib: fix GIT_TEST_SANITIZE_LEAK_LOG
Date: Fri, 15 Sep 2023 07:29:06 -0400 [thread overview]
Message-ID: <20230915112906.GA3125427@coredump.intra.peff.net> (raw)
In-Reply-To: <2890b210-c42f-41cf-e676-0b1c56310f73@gmail.com>
On Fri, Sep 15, 2023 at 02:28:15AM +0200, Rubén Justo wrote:
> > And the problem is in (3). You switch it to trigger only if we have no
> > failures (fixing the inversion). But should we have the same a/b split
> > for this case? I.e.:
> >
> > 3a. if we saw no test failures, invert to cause a failure
> > 3b. we saw other failures; do not invert, but _do_ mention that the
> > log found extra leaks
> >
> > In 3b we are explaining to the user what happened. Though maybe it is
> > not super important, because I think we'd have dumped the log contents
> > anyway?
>
> I think so too. At that point we've already dumped the contents of the
> $TEST_RESULTS_SAN_FILE file.
>
> IMO, when $test_failure is zero (the "if" I'm touching), the message
> makes sense not so much to say that a leak has been found, but rather
> because we're forcing the non-zero exit.
>
> But when $test_failure is not zero, after we've already dumped the
> log, maybe this is somewhat redundant:
>
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 87cfea9e9a..b160ae3f7a 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -1267,6 +1267,8 @@ check_test_results_san_file_ () {
> then
> say "With GIT_TEST_SANITIZE_LEAK_LOG=true our logs revealed a memory leak, exit non-zero!" &&
> invert_exit_code=t
> + else
> + say "With GIT_TEST_SANITIZE_LEAK_LOG=true our logs revealed a memory leak"
> fi
> }
>
> However, if you or anyone else thinks it adds value, I have no objection
> to re-roll with it.
I'm on the fence. It is probably not a big deal, and my biggest issue is
just that I had to walk through the explanation in my previous mail to
convince myself the change was not missing an important case.
But having done so, the main value in re-rolling would be preventing
somebody else from reading the code and having the same question. But
this discussion in the archive is probably sufficient.
-Peff
next prev parent reply other threads:[~2023-09-15 11:29 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-09-09 23:03 [PATCH 0/2] fix GIT_TEST_SANITIZE_LEAK_LOG=true Rubén Justo
2023-09-09 23:08 ` [PATCH 1/2] test-lib: prevent misuses of --invert-exit-code Rubén Justo
2023-09-10 1:59 ` Eric Sunshine
2023-09-10 22:58 ` Rubén Justo
2023-09-12 8:35 ` Jeff King
2023-09-15 0:10 ` Rubén Justo
2023-09-09 23:09 ` [PATCH 2/2] test-lib: fix GIT_TEST_SANITIZE_LEAK_LOG Rubén Justo
2023-09-12 8:27 ` Jeff King
2023-09-15 0:28 ` Rubén Justo
2023-09-15 11:29 ` Jeff King [this message]
2023-09-15 17:51 ` Junio C Hamano
2023-09-16 5:32 ` Jeff King
2023-09-15 17:49 ` Junio C Hamano
2023-09-22 20:38 ` [PATCH v2] " Rubén Justo
2023-09-23 6:24 ` Jeff King
2023-09-23 8:11 ` Rubén Justo
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=20230915112906.GA3125427@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
--cc=rjusto@gmail.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).