Re: What's cooking in git.git (Jan 2022, #03; Thu, 13)
- From
Patrick Steinhardt <ps@pks.im>
- Date
- Jan 17, 2022, 07:18 UTC
- Message-ID
- <YeUYR8TwJf+31wcl@ncase>
- In-Reply-To
- <220114.86fspqrxbw.gmgdl@evledraar.gmail.com>
On Fri, Jan 14, 2022 at 07:12:15PM +0100, Ævar Arnfjörð Bjarmason wrote:
Show 65 quoted lines
>
> On Thu, Jan 13 2022, Junio C Hamano wrote:
>
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> >> There are a few "oops, what we merged recently is broken" topics
> >> that still are not in 'master', but otherwise what we have should
> >> be pretty much what we'll have in the final one.
> >>
> >> - I am reasonably happy with ab/refs-errno-cleanup (just one patch)
> >> that fixes the incorrect state of the code left by the earlier
> >> parts of the topic that have already been merged during this
> >> cycle.
> >>
> >> - I am also OK with ab/reftable-build-fixes (two patches), one for
> >> general type correctness fix, the other for helping older sub-C99
> >> compilers.
> >>
> >> If there are fixes for regressions that we introduced during this
> >> cycle other than these two topics, I certainly am missing them, so
> >> please holler loudly and quickly, hopefully in time for me to tag
> >> the -rc1 tomorrow.
> >
> > Oh, by the way, the tip of 'seen' has consistently failing the
> > leak-check test. I didn't have chance, time or energy to see if
> > they are failing merely because an existing test script that used to
> > be leak-clean gained a use of command that has been known to be
> > leak-unclean without introducing any new leaks, or our recent change
> > did introduce new leaks to commands that have been leak-clean.
> > Somebody with too much time on their hand should go in and check to
> > help, before CI testing on 'seen' becomes useful again.
>
> It's a regression in
> ps/avoid-unnecessary-hook-invocation-with-packed-refs, Patrick could you
> look into it? On your current "seen" doing a:
>
> git revert -m 1 48b388cbf31
>
> Will make those 3x failing tests pass:
> https://github.com/git/git/runs/4811683950?check_suite_focus=true
>
> (That commit being: 48b388cbf31 (Merge branch
> 'ps/avoid-unnecessary-hook-invocation-with-packed-refs' into seen,
> 2022-01-13))
>
> I didn't have much time to look now, but this mostly untested fix-up
> fixes up the topic under SANITIZE=leak (but may break something else). I
> ran the broken tests with SANITIZE=leak, and the normal tests without
> SANITIZE=leak, but didn't have time for further testing:
>
> diff --git a/refs/packed-backend.c b/refs/packed-backend.c
> index ff96ee482a0..b8012f97009 100644
> --- a/refs/packed-backend.c
> +++ b/refs/packed-backend.c
> @@ -1577,6 +1577,7 @@ int packed_refs_delete_refs(struct ref_store *ref_store,
> error(_("could not delete references: %s"), err.buf);
> }
>
> + ref_transaction_free(transaction);
> strbuf_release(&err);
> return ret;
> }
>
> I.e. the moving around of the ref_transaction_free() is at fault
> somehow, probably...Thanks for digging! The bug is actually in the files backend, where `files_delete_refs()` has two different exit paths, but I added the free of the packed-refs backend only to one of both. So the following patch fixes it:
diff --git a/refs/files-backend.c b/refs/files-backend.c index 9a20cb8fa8..844918cbd8 100644 --- a/refs/files-backend.c +++ b/refs/files-backend.c @@ -1280,6 +1280,7 @@ static int files_delete_refs(struct ref_store *ref_store, const char *msg, result |= error(_("could not remove reference %s"), refname); } + ref_transaction_free(transaction); strbuf_release(&err); return result; I'll send a reroll of my series. Patrick