Re: git 2.16.0 segfaults on clone of specific repo

[Duy Nguyen <pclouds@gmail.com>]

On Fri, Jan 19, 2018 at 2:40 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:
> On Fri, Jan 19, 2018 at 12:31:58PM +0700, Duy Nguyen wrote:
>> 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.

And not stepping back to think for a bit. I realized now that if I
just mounted a vfat filesystem, I could have verified it much quicker.
It does crash on linux with similar stack trace.

(gdb) bt
#0  0x000000000055809f in is_empty_blob_sha1 (sha1=0x8fa6d4 "\236") at
cache.h:1055
#1  0x0000000000558acd in ce_match_stat_basic (ce=0x8fa690,
st=0x7fffffffcd20) at read-cache.c:272
#2  0x0000000000558c78 in ie_match_stat (istate=0x8e9fc0 <the_index>,
ce=0x8fa690, st=0x7fffffffcd20, options=5) at read-cache.c:342
#3  0x0000000000501e01 in checkout_entry (ce=0x8fa690,
state=0x7fffffffcea0, topath=0x0) at entry.c:424
#4  0x00000000005c8ea0 in check_updates (o=0x7fffffffd060) at unpack-trees.c:383
#5  0x00000000005cb2bb in unpack_trees (len=1, t=0x7fffffffd010,
o=0x7fffffffd060) at unpack-trees.c:1382
#6  0x00000000004214ca in checkout (submodule_progress=1) at builtin/clone.c:750
#7  0x00000000004229ce in cmd_clone (argc=1, argv=0x7fffffffd840,
prefix=0x0) at builtin/clone.c:1191
#8  0x0000000000405846 in run_builtin (p=0x89a908 <commands+456>,
argc=2, argv=0x7fffffffd840) at git.c:346
#9  0x0000000000405af7 in handle_builtin (argc=2, argv=0x7fffffffd840)
at git.c:554
#10 0x0000000000405c8f in run_argv (argcp=0x7fffffffd6fc,
argv=0x7fffffffd6f0) at git.c:606
#11 0x0000000000405e31 in cmd_main (argc=2, argv=0x7fffffffd840) at git.c:683
#12 0x00000000004a3231 in main (argc=3, argv=0x7fffffffd838) at common-main.c:43

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

There's a travis job running "on windows" (I don't what it really
means) so it might help actually. This vim-colorschemes repository has
shown up in git mailing list before, I think. We probably should just
add it as part of our regression tests ;-)
-- 
Duy