On Thu, Aug 24, 2023 at 05:02:38PM -0400, Jeff King wrote: > On Thu, Aug 24, 2023 at 02:40:38PM -0400, Taylor Blau wrote: > > > In the topic merged via 5a4f8381b6 (Merge branch > > 'ab/mark-leak-free-tests', 2021-10-25), a handful of tests in the suite > > were marked as leak-free. > > > > As far as I can tell, each patch from that series ran tests from a > > handful of subject areas, such as "some ls-files tests", or "all trace2 > > tests". This left some gaps in which tests had and hadn't been audited > > to be leak-free. > > > > This patch closes those gaps by exporting TEST_PASSES_SANITIZE_LEAK=true > > before sourcing t/test-lib.sh on most remaining leak-free tests. This > > list was compiled by doing: > > > > $ make SANITIZE=leak > > $ make \ > > GIT_TEST_PASSING_SANITIZE_LEAK=check \ > > GIT_TEST_SANITIZE_LEAK_LOG=true \ > > GIT_TEST_OPTS=-vi test > > So having resolved my "oops, lsan logs are racy" problem, my system now > agrees with yours on which tests are now leak-free. And we definitely > _were_ leak free less than year ago when I posted that other patch. So > I'm not sure I buy the "these were missed in 5a4f8381b6" logic. Phew ;-). Thanks for chasing that down, I'm glad that our two sides agree. > The one in t5571, I mentioned earlier that I bisected to 861c56f6f9 > (branch: fix a leak in setup_tracking, 2023-06-11). > > The one in t7516 seems to have been fixed by 866b43e644 > (do_read_index(): always mark index as initialized unless erroring out, > 2023-06-29). > > I found both by bisecting between v2.39.0 (which shows the leak) and > v2.42.0 (which doesn't). Much appreciated. I'm happy to fold those details into a new round if you think they are useful enough to live in the commit history. I could grab your patch as a preparatory step, too. But if you are happy with this as-is, I am too. Thanks, Taylor
