On Sun, Jul 17 2022, Junio C Hamano wrote:
> * jk/diff-files-cleanup-fix (2022-07-12) 1 commit
> (merged to 'next' on 2022-07-13 at 9db5235d01)
> + diff-files: move misplaced cleanup label
>
> An earlier attempt to plug leaks placed a clean-up label to jump to
> at a bogus place, which as been corrected.
>
> Will merge to 'master'.
> source: <Ys0c0ePxPOqZ/5ck@xxxxxxxxxxxxxxxxxxxxxxx>
(As noted before) that fix looks good, thanks Jeff!
But here's a gentle *poke* about picking up [1], which is a related
follow-up series (but applies directly on master).
It fixes some other minor issues in my earlier release_revisions()
series, and then goes on to fix other common memory leaks that didn't
make it into that initial series.
These in particular & somewhat tricky or non-obvious, and could use
careful review:
https://lore.kernel.org/git/patch-4.6-9bff7b10197-20220713T130511Z-avarab@xxxxxxxxx/
https://lore.kernel.org/git/patch-6.6-4a581a4a6ce-20220713T130511Z-avarab@xxxxxxxxx/
The latter of those proposes to fix what's a common leak pattern in the
codebase in a particular way, I'd be interested to know what people
think of that approach.
There was a related earlier discussion between me and Glen at:
https://lore.kernel.org/git/220713.86o7xs3g76.gmgdl@xxxxxxxxxxxxxxxxxxx/
I.e. whether we should do an xstrdup() (or equivalent) in those cases,
so we wouldn't have to mix up free()-able data (strvec etc) with
un-free() able (main()'s "argv") in various APIs.
There are more drastic ways to address it, but I think that 6/6 is the
best trade-off in terms of a narrow fix & fixing that class of leak.
1. https://lore.kernel.org/git/cover-0.6-00000000000-20220713T130511Z-avarab@xxxxxxxxx/
