git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 3/6] test-lib: rely on logs to detect leaks

From
Patrick Steinhardt <ps@pks.im>
Date
Jan 3, 2025, 12:05 UTC
Message-ID
<Z3fSj-NsSg2El2wI@pks.im>
In-Reply-To
<20250101201444.GC3305462@coredump.intra.peff.net>
On Wed, Jan 01, 2025 at 03:14:44PM -0500, Jeff King wrote:
Show 27 quoted lines
> 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
Previous: Jeff KingNext: Jeff King
Message 9 of 37 in “What's cooking in git.git (Dec 2024, #11; Mon, 30)”
  1. Junio C HamanoDec 30, 2024
  2. René ScharfeDec 31, 2024
  3. Patrick SteinhardtJan 3, 2025
  4. a less-invasive racy-leak fix, was Re: What's cooking in git.git (Dec 2024, #11; Mon, 30)Jeff King, Jan 1, 2025
  5. 0/6 a less-invasive racy-leak fixJeff King, Jan 1, 2025
  6. 1/6 test-lib: use individual lsan dir for --stress runsJeff King, Jan 1, 2025
  7. 2/6 Revert "index-pack: spawn threads atomically"Jeff King, Jan 1, 2025
  8. 3/6 test-lib: rely on logs to detect leaksJeff King, Jan 1, 2025
  9. Patrick SteinhardtJan 3, 2025
  10. Jeff KingJan 3, 2025
  11. 4/6 test-lib: simplify leak-log checkingJeff King, Jan 1, 2025
  12. Patrick SteinhardtJan 3, 2025
  13. Jeff KingJan 3, 2025
  14. Patrick SteinhardtJan 6, 2025
  15. Jeff KingJan 7, 2025
  16. 5/6 test-lib: check leak logs for presence of DEDUP_TOKENJeff King, Jan 1, 2025
  17. 6/6 test-lib: ignore leaks in the sanitizer's thread codeJeff King, Jan 1, 2025
  18. Patrick SteinhardtJan 3, 2025
  19. Jeff KingJan 3, 2025
  20. Patrick SteinhardtJan 6, 2025
  21. 0/3 lsan test-lib readabilityJeff King, Jan 7, 2025
  22. 1/3 test-lib: invert return value of check_test_results_san_file_emptyJeff King, Jan 7, 2025
  23. 2/3 test-lib: simplify lsan results checkJeff King, Jan 7, 2025
  24. Patrick SteinhardtJan 7, 2025
  25. Jeff KingJan 9, 2025
  26. Patrick SteinhardtJan 9, 2025
  27. Junio C HamanoJan 7, 2025
  28. Jeff KingJan 9, 2025
  29. 3/3 test-lib: add a few comments to LSan log checkingJeff King, Jan 7, 2025
  30. Patrick SteinhardtJan 7, 2025
  31. Junio C HamanoJan 2, 2025
  32. Jeff KingJan 2, 2025
  33. Chris TorekJan 2, 2025
  34. Junio C HamanoJan 2, 2025
  35. Jeff KingJan 2, 2025
  36. Junio C HamanoJan 2, 2025
  37. Jeff KingJan 2, 2025

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.