git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH] t4204 is not sanitizer clean at all
Date: Fri, 17 Dec 2021 23:23:00 +0100	[thread overview]
Message-ID: <211217.86a6gyyihr.gmgdl@evledraar.gmail.com> (raw)
In-Reply-To: <xmqqk0g32c06.fsf@gitster.g>


On Fri, Dec 17 2021, Junio C Hamano wrote:

> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>> This change looks good to me.
>>
>> FWIW this is not a mistake on my part, but something I'm perfectly aware
>> of. I don't consider it to be "brekage".
>>
>> We have plenty of place in the test suite where we hide exit codes on
>> the LHS of a pipe, or where we call a function that doesn't &&-chain its
>> git invocations.
>>
>> In those cases we can and usually will "succeed" under LSAN, because it
>> allows the program to emit its full output, and will abort() at the very
>> end.
>
> But pipes do not hide ONLY deaths by sanitizer.  And by relying on
> the presence of pipe hiding deaths of git tools to mark the script
> sanitizer-clean, the TEST_PASSES_SANITIZE_LEAK=true line adds an
> unnecessary road-block for those who are cleaning up the "git whose
> crash are hidden by being on the left hand side of the pipe"
> pattern.
>
> I do not know what to call it if not "breakage".

Yes it's broken as far as the test is concerned. I meant as far as
"GIT_TEST_PASSING_SANITIZE_LEAK" goes I consider it somewhere between
"meh" and "don't care yet".

I.e. these are pretty irrelevant for finding leaks, as we've got a huge
deluge of them elsewhere. At some point we might have a last few stray
memory leaks in git hidden by such patterns, but we're very far away
from that.

Sometimes fixing those is trivial as in 3247919a758 (commit-graph tests:
fix error-hiding graph_git_two_modes() helper, 2021-10-15), and
sometimes we'll find that the test was broken all along in some other
subtle way, as in the a046aa38ca9 (commit-graph tests: fix another
graph_git_two_modes() helper, 2021-10-15) follow-up.

But as to the "roadblock" I don't mind the
TEST_PASSES_SANITIZE_LEAK=true being removed from the script at the
slightest sign of trouble. Nobody should have to shift gears and chase
down some memory leak in "git log" just because they needed it for their
test setup.

And I'd very much prefer that to UNLEAK() just to avoid that
TEST_PASSES_SANITIZE_LEAK=true removal, because it makes fixing the leak
itself harder as far as what topic to target, re-adding
TEST_PASSES_SANITIZE_LEAK=true once it's fixed etc. goes.

  reply	other threads:[~2021-12-17 22:27 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-12-13 22:03 [PATCH V3 1/2] git-apply: add --quiet flag Jerry Zhang
2021-12-13 22:03 ` [PATCH V5 2/2] git-apply: add --allow-empty flag Jerry Zhang
2021-12-16  1:40   ` Junio C Hamano
2021-12-16 23:11     ` [PATCH] t4204 is not sanitizer clean at all Junio C Hamano
2021-12-17  4:39       ` Ævar Arnfjörð Bjarmason
2021-12-17 20:48         ` Junio C Hamano
2021-12-17 22:23           ` Ævar Arnfjörð Bjarmason [this message]
2021-12-16 23:37     ` [PATCH] format-patch: mark rev_info with UNLEAK Junio C Hamano
2021-12-17  4:51     ` [PATCH V5 2/2] git-apply: add --allow-empty flag Ævar Arnfjörð Bjarmason
2021-12-17 20:48       ` Junio C Hamano
2021-12-17 22:28         ` Ævar Arnfjörð Bjarmason
2021-12-17 22:32         ` Junio C Hamano
2021-12-13 22:30 ` [PATCH V3 1/2] git-apply: add --quiet flag 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

  List information: http://vger.kernel.org/majordomo-info.html

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

  git send-email \
    --in-reply-to=211217.86a6gyyihr.gmgdl@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --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.
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).