Re: [PATCH 0/2] Squash leaks in t0000

From: Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date: Sep 21, 2021, 23:01 UTC
Message-ID: <87r1dh8r62.fsf@evledraar.gmail.com>
In-Reply-To: <xmqq4kafcesa.fsf@gitster.g>

On Mon, Sep 20 2021, Junio C Hamano wrote:

Show 18 quoted lines

> "Andrzej Hunt via GitGitGadget" <gitgitgadget@gmail.com> writes:
>
>> Carlo points out that t0000 currently doesn't pass with leak-checking
>> enabled in:
>> https://public-inbox.org/git/CAPUEsphMUNYRACmK-nksotP1RrMn09mNGFdEHLLuNEWH4AcU7Q@mail.gmail.com/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@ahunt.org/
2. https://lore.kernel.org/git/87a6k8daeu.fsf@evledraar.gmail.com/