On Thu, Sep 26, 2024 at 04:19:24PM +0200, Patrick Steinhardt wrote: > On Tue, Sep 24, 2024 at 05:38:36PM -0400, Jeff King wrote: > > If you are trying to find and fix leaks in a large test script, it can > > be overwhelming to see the leak logs for every test at once. The > > previous commit let you use "--immediate" to see the logs after the > > first failing test, but this isn't always the first leak. As discussed > > there, we may see leaks from previous tests that didn't happen to fail. > > > > To catch those, let's check for any logs that appeared after each test > > snippet is run, meaning that in a SANITIZE=leak build, any leak is an > > immediate failure of the test snippet. > > > > This check is mostly free in non-leak builds (just a "test -z"), and > > only a few extra processes in a leak build, so I don't think the > > overhead should matter (if it does, we could probably optimize for the > > common "no logs" case without even spending a process). > > So previously, `--immediate` didn't detect tests that should have failed > because they were leaks, and now it does? Sounds like a sensible change > to me, too. Yes, though just to be pedantic, they are marked as failures even without --immediate. It is just that doing so is a lot more useful with --immediate, since otherwise we'd find the leaks at the end (but even that it may still be useful to point to a particular test). So it really is "if you are in a SANITIZE=leak build, generating a leak log fails the test even if it would otherwise pass". -Peff
