git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH] commit: fix "author_ident" leak

From
Ævar Arnfjörð Bjarmason <avarab@gmail.com>
Date
May 17, 2022, 13:48 UTC
Message-ID
<220517.86fsl86z1s.gmgdl@evledraar.gmail.com>
In-Reply-To
<xmqqzgjmcqlg.fsf@gitster.g>
On Thu, May 12 2022, Junio C Hamano wrote:
Show 26 quoted lines
> Since 4c28e4ada03 (commit: die before asking to edit the log
> message, 2010-12-20), we have been "leaking" the "author_ident" when
> prepare_to_commit() fails.  Instead of returning from right there,
> introduce an exit status variable and jump to the clean-up label
> at the end.
>
> Instead of explicitly releasing the resource with strbuf_release(),
> mark the variable with UNLEAK() at the end, together with two other
> variables that are already marked as such.  If this were in a
> utility function that is called number of times, but these are
> different, we should explicitly release resources that grow
> proportionally to the size of the problem being solved, but
> cmd_commit() is like main() and there is no point in spending extra
> cycles to release individual pieces of resource at the end, just
> before process exit will clean everything for us for free anyway.
>
> This fixes a leak demonstrated by e.g. "t3505-cherry-pick-empty.sh",
> but unfortunately we cannot mark it or other affected tests as passing
> now with "TEST_PASSES_SANITIZE_LEAK=true" as we'll need to fix many
> other memory leaks before doing so.
>
> Incidentally there are two tests that always passes the leak checker
> with or without this change.  Mark them as such.
>
> This is based on an earlier patch by Ævar, but takes a different
> approach that is more maintainable.

We've talked about UNLEAK() v.s. strbuf_release() elsewhere, so let's leave that aside. I know your preferences in that area.

But even accounting for that, I don't see what the "more maintainable" here refers to. The approach I suggested would s/UNLEAK/strbuf_release/ in the 4th hunk, but otherwise be equivalent.

Surely both are about as easy to maintain. To the extent that there's any difference at all I'd think the strbuf_release() would pull ahead, as it's guaranteed to do the right thing with all of our memory analysis tooling (some of which will have a noop UNLEAK()).

Just a small question, I see this is in "next" already, and I'm fine with this change either way.

Previous: Junio C HamanoNext: Junio C Hamano
Message 11 of 12 in “commit: trivial leak fix, add 2 tests to linux-leaks CI”
  1. 0/2 commit: trivial leak fix, add 2 tests to linux-leaks CIÆvar Arnfjörð Bjarmason, Feb 16, 2022
  2. 1/2 commit: fix "author_ident" leakÆvar Arnfjörð Bjarmason, Feb 16, 2022
  3. Junio C HamanoFeb 16, 2022
  4. 2/2 commit: use strbuf_release() instead of UNLEAK()Ævar Arnfjörð Bjarmason, Feb 16, 2022
  5. Junio C HamanoFeb 16, 2022
  6. Junio C HamanoFeb 16, 2022
  7. Whether to keep using UNLEAK() in built-ins (was: [PATCH 2/2] commit: use strbuf_release() instead of UNLEAK())Ævar Arnfjörð Bjarmason, Feb 18, 2022
  8. Junio C HamanoFeb 18, 2022
  9. Ævar Arnfjörð BjarmasonFeb 18, 2022
  10. commit: fix "author_ident" leakJunio C Hamano, May 12, 2022
  11. Ævar Arnfjörð BjarmasonMay 17, 2022
  12. Junio C HamanoMay 18, 2022

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.