Re: [PATCH 06/11] sparse-checkout: avoid using internal API of unpack-trees, take 2

[Elijah Newren <newren@gmail.com>]

On Fri, Feb 24, 2023 at 3:22 PM Jonathan Tan <jonathantanmy@google.com> wrote:
>
> "Elijah Newren via GitGitGadget" <gitgitgadget@gmail.com> writes:
> > From: Elijah Newren <newren@gmail.com>
> >
> > 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@gmail.com>
> > ---
> >  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.