git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick Steinhardt <ps@pks.im>
To: Jeff King <peff@peff.net>
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH 3/6] test-lib: rely on logs to detect leaks
Date: Fri, 3 Jan 2025 13:05:41 +0100	[thread overview]
Message-ID: <Z3fSj-NsSg2El2wI@pks.im> (raw)
In-Reply-To: <20250101201444.GC3305462@coredump.intra.peff.net>

On Wed, Jan 01, 2025 at 03:14:44PM -0500, Jeff King wrote:
> When we run with sanitizers, we set abort_on_error=1 so that the tests
> themselves can detect problems directly (when the buggy program exits
> with SIGABRT). This has one blind spot, though: we don't always check
> the exit codes for all programs (e.g., helpers like upload-pack invoked
> behind the scenes).
> 
> For ASan and UBSan this is mostly fine; they exit as soon as they see an
> error, so the unexpected abort of the program causes the test to fail
> anyway.
> 
> But for LSan, the program runs to completion, since we can only check
> for leaks at the end. And in that case we could miss leak reports. And
> thus we started checking LSan logs in faececa53f (test-lib: have the
> "check" mode for SANITIZE=leak consider leak logs, 2022-07-28).
> Originally the logs were optional, but logs are generated (and checked)
> always as of 8c1d6691bc (test-lib: GIT_TEST_SANITIZE_LEAK_LOG enabled by
> default, 2024-07-11). And we even check them for each test snippet, as
> of cf1464331b (test-lib: check for leak logs after every test,
> 2024-09-24).
> 
> So now aborting on error is superfluous for LSan! We can get everything
> we need by checking the logs. And checking the logs is actually
> preferable, since it gives us more control over silencing false
> positives (something we do not yet do, but will soon).
> 
> So let's tell LSan to just exit normally, even if it finds leaks. We can
> do so with exitcode=0, which also suppresses the abort_on_error flag.

The only downside I can think of is that we now run the whole testcase
to completion before checking for leaks, whereas beforehand we most
likely aborted the testcase on hitting the first leak. It follows that
we may now have multiple leak reports, and it is not immediately clear
which of the commands has actually been failing.

I think we're now in a clean-enough state regarding memory leaks that
this isn't a huge issue anymore though.

Patrick

  reply	other threads:[~2025-01-03 12:05 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-12-30 17:33 What's cooking in git.git (Dec 2024, #11; Mon, 30) Junio C Hamano
2024-12-31 17:27 ` René Scharfe
2025-01-03  7:39   ` Patrick Steinhardt
2025-01-01 19:14 ` a less-invasive racy-leak fix, was " Jeff King
2025-01-01 20:12   ` [PATCH 0/6] a less-invasive racy-leak fix Jeff King
2025-01-01 20:12     ` [PATCH 1/6] test-lib: use individual lsan dir for --stress runs Jeff King
2025-01-01 20:12     ` [PATCH 2/6] Revert "index-pack: spawn threads atomically" Jeff King
2025-01-01 20:14     ` [PATCH 3/6] test-lib: rely on logs to detect leaks Jeff King
2025-01-03 12:05       ` Patrick Steinhardt [this message]
2025-01-03 20:10         ` Jeff King
2025-01-01 20:17     ` [PATCH 4/6] test-lib: simplify leak-log checking Jeff King
2025-01-03 12:05       ` Patrick Steinhardt
2025-01-03 20:24         ` Jeff King
2025-01-06  7:56           ` Patrick Steinhardt
2025-01-07  7:01             ` Jeff King
2025-01-01 20:18     ` [PATCH 5/6] test-lib: check leak logs for presence of DEDUP_TOKEN Jeff King
2025-01-01 20:21     ` [PATCH 6/6] test-lib: ignore leaks in the sanitizer's thread code Jeff King
2025-01-03 12:05       ` Patrick Steinhardt
2025-01-03 20:26         ` Jeff King
2025-01-06  7:56           ` Patrick Steinhardt
2025-01-07  7:04     ` [PATCH 0/3] lsan test-lib readability Jeff King
2025-01-07  7:05       ` [PATCH 1/3] test-lib: invert return value of check_test_results_san_file_empty Jeff King
2025-01-07  7:07       ` [PATCH 2/3] test-lib: simplify lsan results check Jeff King
2025-01-07  7:37         ` Patrick Steinhardt
2025-01-09  7:57           ` Jeff King
2025-01-09 10:00             ` Patrick Steinhardt
2025-01-07 16:23         ` Junio C Hamano
2025-01-09  7:59           ` Jeff King
2025-01-07  7:08       ` [PATCH 3/3] test-lib: add a few comments to LSan log checking Jeff King
2025-01-07  7:37         ` Patrick Steinhardt
2025-01-02  0:25   ` a less-invasive racy-leak fix, was Re: What's cooking in git.git (Dec 2024, #11; Mon, 30) Junio C Hamano
2025-01-02  2:32     ` Jeff King
2025-01-02  2:41       ` Chris Torek
2025-01-02 14:42       ` Junio C Hamano
2025-01-02 19:06         ` Jeff King
2025-01-02 19:33           ` Junio C Hamano
2025-01-02  3:24     ` 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=Z3fSj-NsSg2El2wI@pks.im \
    --to=ps@pks.im \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /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).