Martin Ågren <martin.agren@xxxxxxxxx> 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.
