On Mon, Sep 20 2021, Junio C Hamano wrote: > "Andrzej Hunt via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes: > >> Carlo points out that t0000 currently doesn't pass with leak-checking >> enabled in: >> https://public-inbox.org/git/CAPUEsphMUNYRACmK-nksotP1RrMn09mNGFdEHLLuNEWH4AcU7Q@xxxxxxxxxxxxxx/T/#m7e40220195d98aee4be7e8593d30094b88a6ee71 >> >> Here's a series that I've sat on for a while, which adds some UNLEAK's to >> "fix" this situation - see the individual patches for a justification of why >> an UNLEAK seems appropriate. > > It seems that discussion on 1/2 seemed to be heading in an > improvement but has petered out? > > I think the simplest fix in these two patches are worth taking, even > if we plan to further improve either by refining the granularity of > UNLEAK application or by introducing repo_clear_revisions() as Carlo > mentions (which is a preferred way to do this if we can manage it), > on top. I think per Andrzej's own [1] it's best to not pick up this series. I've got a lot of memory leak fixes queued up locally, I'm just waiting on the SANITIZE=leak CI mode to land on master so I can add new tests to the whitelist as I fix the memory leaks, that includes "real" fixes for the ones Andrzej's added "UNLEAK()"'s for here. Hence my meniton of this sort of thing being counter-productive[2], i.e. I'd need to monkeypatch revert this on top just to make sure I was still finding leaks that are hidden by these new UNLEAK() (which hide some really common ones). 1. https://lore.kernel.org/git/05754f9c-cd58-30f5-e2d3-58b9221d2770@xxxxxxxxx/ 2. https://lore.kernel.org/git/87a6k8daeu.fsf@xxxxxxxxxxxxxxxxxxx/
