Re: git 2.16.0 segfaults on clone of specific repo

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Jan 19, 2018, 07:40 UTC
Message-ID: <20180119074001.GA55929@flurp.local>
In-Reply-To: <CACsJy8BTFm_0sv=roL1OKKW=1DyU3vqD50NKyHg3KQ7G+mAepQ@mail.gmail.com>

On Fri, Jan 19, 2018 at 12:31:58PM +0700, Duy Nguyen wrote:

Show 18 quoted lines

> On Fri, Jan 19, 2018 at 10:40 AM, brian m. carlson
> > I'm still extremely puzzled as to why this doesn't fail on Linux.  If
> > it's failing in this case, it should very, very clearly fail all the
> > time we access an empty blob or an empty tree.[...]
> 
> I think it's file system related, case-insensitive one in particular.
> 
> The call trace posted at the beginning of this thread should never
> trigger for an initial clone. You only check if an _existing_ entry
> matches what you are about to checkout when you switch trees. For this
> to happen at clone time, I suppose you have to checkout entry "A",
> then re-checkout "A" again. Which can only happen on case-insensitive
> file systems and a case-sensitive repo where the second "A" might
> actually be "a".
> [...]
> On Linux, after I hacked all over the place to force ce_match_stat()
> to eventually call index_fd() which in turns must use one of the
> hashing function, I got a crash.

Nice detective work. This particular manifestation is caught by the following test which fails without brian's patch on MacOS (and presumably Windows) and succeeds with it. On Linux and BSD, it will of course succeed always, so I'm not sure how much practical value it has.

--- >8 ---
hex2oct() {
	perl -ne 'printf "\\%03o", hex for /../g'
}

test_expect_success 'clone on case-insensitive fs' '
	o=$(git hash-object -w --stdin </dev/null | hex2oct) &&
	t=$(printf "100644 X\0${o}100644 x\0${o}" |
		   git hash-object -w -t tree --stdin) &&
	c=$(git commit-tree -m bogus $t) &&
	git update-ref refs/heads/bogus $c &&
	git clone -b bogus . bogus
'
--- >8 ---

(hex2oct lifted from t1007/t1450)