Re: [PATCH v4 08/19] worktree: fix a trivial leak in prune_worktrees()
- From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
- Date
- Jan 18, 2023, 23:03 UTC
- Message-ID
- <230119.86h6wnwihp.gmgdl@evledraar.gmail.com>
- In-Reply-To
- <xmqqedrr6cnp.fsf@gitster.g>
On Wed, Jan 18 2023, Junio C Hamano wrote:
Show 19 quoted lines
> Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:
>
>>> diff --git c/builtin/branch.c w/builtin/branch.c
>>> index f63fd45edb..4fe7757670 100644
>>> --- c/builtin/branch.c
>>> +++ w/builtin/branch.c
>>> @@ -742,6 +742,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
>>> if (filter.abbrev == -1)
>>> filter.abbrev = DEFAULT_ABBREV;
>>> filter.ignore_case = icase;
>>> + UNLEAK(filter);
>>>
>>> finalize_colopts(&colopts, -1);
>>> if (filter.verbose) {
>>
>> I'll send a v5 re-roll without this change, sorry.
>
> I'd rather see your reroll with the above addition of UNLEAK() than
> without it, to fix the breakage.I don't mind that UNLEAK() being in-tree until a better fix for that leak, but doesn't the v5 I sent also address this?
The issue was that I mis-marked a test as passing, when it only passed depending on my local compiler (-fsanitize=leak is fickle sometimes). Now that we're not marking that test as leak-free there's no need for the UNLEAK() for now, no?
Or is there some edge case I didn't spot/notice?
1. https://lore.kernel.org/git/cover-v5-00.19-00000000000-20230118T120334Z-avarab@gmail.com/