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

[Junio C Hamano <gitster@pobox.com>]

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

> 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.