On Fri, Feb 24, 2023 at 3:22 PM Jonathan Tan <jonathantanmy@xxxxxxxxxx> wrote:
>
> "Elijah Newren via GitGitGadget" <gitgitgadget@xxxxxxxxx> writes:
> > From: Elijah Newren <newren@xxxxxxxxx>
> >
> > Commit 2f6b1eb794 ("cache API: add a "INDEX_STATE_INIT" macro/function,
> > add release_index()", 2023-01-12) mistakenly added some initialization
> > of a member of unpack_trees_options that was intended to be
> > internal-only. Further, it served no purpose as it simply duplicated
> > the initialization that unpack-trees.c code was already doing.
> >
> > Signed-off-by: Elijah Newren <newren@xxxxxxxxx>
> > ---
> > builtin/sparse-checkout.c | 1 -
> > 1 file changed, 1 deletion(-)
> >
> > diff --git a/builtin/sparse-checkout.c b/builtin/sparse-checkout.c
> > index 4b7390ce367..8d5ae6f2a60 100644
> > --- a/builtin/sparse-checkout.c
> > +++ b/builtin/sparse-checkout.c
> > @@ -217,7 +217,6 @@ static int update_working_directory(struct pattern_list *pl)
> > o.head_idx = -1;
> > o.src_index = r->index;
> > o.dst_index = r->index;
> > - index_state_init(&o.result, r);
> > o.skip_sparse_checkout = 0;
> >
> > setup_work_tree();
>
> The commit message seems to imply that in this code path, there is some
> code in unpack-trees.c that runs index_state_init(), but that doesn't
> seem to be the case. memset-ting the result field with a junk value
> causes valgrind to fail with the following trace:
>
> ==2035705== Invalid read of size 8
> ==2035705== at 0x30D982: lazy_init_name_hash (name-hash.c:602)
> ==2035705== by 0x30DDDA: index_file_exists (name-hash.c:721)
> ==2035705== by 0x3F71A8: check_ok_to_remove (unpack-trees.c:2430)
> ==2035705== by 0x3F74EE: verify_absent_1 (unpack-trees.c:2495)
> ==2035705== by 0x3F75C6: verify_absent_sparse (unpack-trees.c:2523)
> ==2035705== by 0x3F2A15: apply_sparse_checkout (unpack-trees.c:566)
> ==2035705== by 0x3F6849: update_sparsity (unpack-trees.c:2147)
> ==2035705== by 0x1FC105: update_working_directory (sparse-checkout.c:228)
>
> so it might be better to move the init invocation to update_sparsity()
> instead of only removing it.
Actually, my commit message was implying o->result is only used by
unpack_trees() and not update_sparsity(). While that implication is
*mostly* true, I forgot about check_ok_to_remove(). Doh!
Thanks for reviewing so carefully; I'll move the initialization to
update_sparsity() instead.
