Subject: [PATCH 0/6] a less-invasive racy-leak fix

From: Jeff King <[email-masked]>
Date: Wed, 1 Jan 2025 15:12:26 -0500

On Wed, Jan 01, 2025 at 02:14:22PM -0500, Jeff King wrote:

> And finally, one other option (that I'm not sure why I didn't consider
> before): can we just ignore the false positives, similar to what we did
> in 370ef7e40d (test-lib: ignore uninteresting LSan output, 2023-08-28).
> I think we'd have to stop doing abort_on_error for the leak checker and
> just rely on the logs, but that's OK (we always check the logs these
> days). And detecting the false positive is a little involved. But this
> seems to work:

So here's a clean series that does that. I'm kicking myself a little for
not going this route immediately, and spending so much time trying to
deal with the actual race in code that is not even ours. :-/

It would replace what's queued in jk/lsan-race-with-barrier, though the
first two patches remain the same.

Since the grep exit codes and inversions are a little tricky, I checked
at each step that we continue to correctly report the leaks found by
doing:

diff --git a/t/helper/test-date.c b/t/helper/test-date.c
index f25512de9a..7bedb51eaf 100644
--- a/t/helper/test-date.c
+++ b/t/helper/test-date.c
@@ -54,8 +54,6 @@ static void show_dates(const char **argv, const char *format)
 
 		printf("%s -> %s\n", *argv, show_date(t, tz, mode));
 	}
-
-	date_mode_release(&mode);
 }
 
 static void parse_dates(const char **argv)

and running "./t0006-date.sh -i" (which should bail on test 23 and
report the full stack trace).

  [1/6]: test-lib: use individual lsan dir for --stress runs
  [2/6]: Revert "index-pack: spawn threads atomically"
  [3/6]: test-lib: rely on logs to detect leaks
  [4/6]: test-lib: simplify leak-log checking
  [5/6]: test-lib: check leak logs for presence of DEDUP_TOKEN
  [6/6]: test-lib: ignore leaks in the sanitizer's thread code

 builtin/index-pack.c |  2 --
 t/test-lib.sh        | 25 +++++++++++--------------
 2 files changed, 11 insertions(+), 16 deletions(-)

-Peff