Re: git 2.16.0 segfaults on clone of specific repo

From: Duy Nguyen <pclouds@gmail.com>
Date: Jan 19, 2018, 08:22 UTC
Message-ID: <CACsJy8AOPDNTbAWzDHd+Oa5PSc1v2qdfcaq60P7X5wznM4VTug@mail.gmail.com>
In-Reply-To: <20180119074001.GA55929@flurp.local>

On Fri, Jan 19, 2018 at 2:40 PM, Eric Sunshine <sunshine@sunshineco.com> wrote:

Show 21 quoted lines

> 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

Show 5 quoted lines

> 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