Re: What's cooking in git.git (Jan 2022, #03; Thu, 13)

[Patrick Steinhardt <ps@pks.im>]

[-- Attachment #1: Type: text/plain, Size: 3573 bytes --]

On Fri, Jan 14, 2022 at 07:12:15PM +0100, Ævar Arnfjörð Bjarmason wrote:
> 
> 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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]