From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: Patrick Steinhardt <ps@pks.im>, git@vger.kernel.org
Subject: Re: [PATCH 2/3] test-lib: simplify lsan results check
Date: Tue, 07 Jan 2025 08:23:34 -0800 [thread overview]
Message-ID: <xmqqmsg2vbi1.fsf@gitster.g> (raw)
In-Reply-To: <20250107070752.GB584668@coredump.intra.peff.net> (Jeff King's message of "Tue, 7 Jan 2025 02:07:52 -0500")
Jeff King <peff@peff.net> writes:
> We want to know if there are any leaks logged by LSan in the results
> directory, so we run "find" on the containing directory and pipe it to
> xargs. We can accomplish the same thing by just globbing in the shell
> and passing the result to grep, which has a few advantages:
>
> - it's one fewer process to run
> ...
> We are now subject to command-line length limits, but that is also true
> of the globbing cat used to show the logs themselves. This hasn't been a
> problem in practice.
Nice to see it mentioned here. And the resulting code does become
simpler to reason about.
> We do need to use "grep -s" for the case that the glob does not expand
> (i.e., there are not any log files at all). This option is in POSIX, and
> has been used in t7407 for several years without anybody complaining.
Also since c625bf0e (git-p4: git-p4 tests with p4 triggers,
2017-07-13) t9831 has also been using it. It is not like a stray
error message about unmatched glob would really matter here, though.
We are not doing 2>&1 to let the downstream of the pipe see it, and
unless the test is run under "-v" option, it wouldn't even be seen.
> This also also naturally handles the case where the surrounding
> directory has already been removed (in which case there are likewise no
> files!), dropping the need to comment about it.
Nice.
Thanks.
next prev parent reply other threads:[~2025-01-07 16:23 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
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 [this message]
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=xmqqmsg2vbi1.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=ps@pks.im \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.