Re: could not freshen shared index ..../sharedindex.0000000000000000000000000000000000000000'

From: Duy Nguyen <pclouds@gmail.com>
Date: Feb 9, 2019, 04:56 UTC
Message-ID: <CACsJy8AzQLvWNq4hGGva=W4CKJAKHXiopF-cVw--wdJE2npdGQ@mail.gmail.com>
In-Reply-To: <xmqqzhr6kxcj.fsf@gitster-ct.c.googlers.com>

On Sat, Feb 9, 2019 at 12:24 AM Junio C Hamano <gitster@pobox.com> wrote:

Show 22 quoted lines

>
> Duy Nguyen <pclouds@gmail.com> writes:
>
> > On Wed, Feb 06, 2019 at 10:25:25AM +0000, Luke Diamand wrote:
> >> I've recently started seeing a lot of this message when doing a rebase:
> >>
> >>    warning: could not freshen shared index
> >> '/home/ldiamand/git/dev_full/.git/worktrees/gcc8-take-2/sharedindex.0000000000000000000000000000000000000000'
> >
> > There are only two places in the code that could print this. The one
> > in read_index_from() can't happen unless is_null_oid() is broken (very
> > very unlikely).
> >
> > The other one is in write_locked_index() which could happen in theory
> > but I don't understand how it got there. If you could build git, could
> > you try this patch and see if it helps?
>
> ... meaning, if it hides the symptom, we'd know the codepath that
> causes a NULL si->base_oid to appear here is the culprit?  Or do you
> mean that it is expected si->base_oid sometimes is NULL and we should
> have been pretending as if si were NULL (i.e. split_index is not being
> used)?

I didn't go that far when I suggested my patch. Looking more at the code, I think we may have written the "link" extension with null oid. Which could trigger this case and is definitely wrong.

> I take it as the latter (i.e. "helps" to narrow down the bug hunting
> field, not "helps" by fixing the bug).

Yeah definitely not the fix (how can I write "I don't know why" in the commit message for the fix). At least now I know I'm on the right track.

Szeder recently fixed some racy bug in split-index.c, which seems fit in this rebase scenario since we'll be updating the index very often in a short period of time. Perhaps that uncovers some case that we don't handle well. I haven't been able to connect the dots though.

-- 
Duy