Re: git write-tree segfault with core.untrackedCache true and nonexistent index

From: Junio C Hamano <gitster@pobox.com>
Date: Jul 22, 2022, 19:41 UTC
Message-ID: <xmqq35etc4vm.fsf@gitster.g>
In-Reply-To: <20220722192559.718264-1-martin.agren@gmail.com>

Martin Ågren <martin.agren@gmail.com> writes:

Show 9 quoted lines

> I can't help but think that e6a653554b was just unlucky enough to
> dereference `istate->repo` and that the real issue is that we're missing
>
> 	if (!istate->repo)
> 		istate->repo = the_repository;
>
> in some strategic place a fair bit earlier. It seems to me like the diff
> below is just papering over the real bug. It's not obvious to me where
> that check would want to go, though. Tao, do you have an idea?

I am not Tao, but thanks for starting to analyze the real issue.

It seems that there are two public entry points to dir.c API that end up calling new_untracked_cache_flags().

One is read_directory(), which is the only caller of validate_untracked_cache() that calls new_untracked_cache_flags(). The callers of read_directory() are supposed to give istate, and it is quite unlikely they are throwing an istate with NULL in istate->repo, simply because read_directory() already makes abundant use of istate->repo.

The other one is add_untracked_cache().

Perhaps backtrace to see where the istate came from would quickly reveal where the real issue lies?

Thanks.