Re: git 2.16.0 segfaults on clone of specific repo

[Eric Sunshine]

On Fri, Jan 19, 2018 at 7:23 PM, brian m. carlson
 wrote:
> On Fri, Jan 19, 2018 at 07:15:45PM -0500, Eric Sunshine wrote:
>> Are you planning on submitting the test as a proper patch as follow-up
>> to [1]? I couldn't quite decide in which test script it should reside.
>
> Sure, I can.  Since you wrote it, may I have permission to add your
> sign-off?

You may...

Signed-off-by: Eric Sunshine 

> I'll try to set up a temporary FAT device and verify that I can
> reproduce the problem on Linux as well.

Re: git 2.16.0 segfaults on clone of specific repo

[brian m. carlson]

On Fri, Jan 19, 2018 at 07:15:45PM -0500, Eric Sunshine wrote:
> Oh, I agree. My original question of its practical value was based
> upon my belief that the full test suite is very rarely run on MacOS
> (partly because there are so few Git developers on MacOS and partly
> because it runs so slowly on the platform, though not nearly as slowly
> as on Windows). However, as soon as I hit "Send", it hit me that the
> problem would also manifest on Windows, and we know that Dscho runs
> the tests regularly on Windows, so I changed my mind. I did consider
> Travis but wasn't sure if it was testing on case-insensitive
> filesystems.
> 
> Are you planning on submitting the test as a proper patch as follow-up
> to [1]? I couldn't quite decide in which test script it should reside.

Sure, I can.  Since you wrote it, may I have permission to add your
sign-off?

I'll try to set up a temporary FAT device and verify that I can
reproduce the problem on Linux as well.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Re: git 2.16.0 segfaults on clone of specific repo

[Eric Sunshine]

On Fri, Jan 19, 2018 at 12:25 PM, Todd Zullinger  wrote:
> Eric Sunshine wrote:
>> 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.
>
> The CASE_INSENSITIVE_FS prereq could be used to avoid
> running the test on systems where it won't provide much
> value, couldn't it?

As mentioned in [1], my original questioning of the practical value of
the test was tied to the belief that the full test suite is probably
rarely run on MacOS, and it wasn't until I pressed "Send" that it hit
me that it would manifest on Windows as well, and that Dscho does test
on Windows regularly. Therefore, the test could have value.

At any rate, the test potentially could catch some sort of future
regression even on case-sensitive filesystems, therefore, it would be
better not to hide it behind CASE_INSENSITIVE_FS.

[1]: 
https://public-inbox.org/git/CAPig+cQmWqQWQrRQHHn=3hn6UFzJxT=9d5kknjht_dt8scg...@mail.gmail.com/

Re: git 2.16.0 segfaults on clone of specific repo

[Eric Sunshine]

On Fri, Jan 19, 2018 at 5:31 PM, brian m. carlson
 wrote:
> On Fri, Jan 19, 2018 at 02:40:02AM -0500, Eric Sunshine wrote:
>> 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.
>
> I'd argue that it's a worthwhile test to have, since it will fail on
> those systems where it's going to be a problem.  Furthermore, people do
> run the tests (as does Travis) on case-insensitive file systems during
> the development cycle, so if we break something in the future, someone
> will notice while we're still in the development cycle.

Oh, I agree. My original question of its practical value was based
upon my belief that the full test suite is very rarely run on MacOS
(partly because there are so few Git developers on MacOS and partly
because it runs so slowly on the platform, though not nearly as slowly
as on Windows). However, as soon as I hit "Send", it hit me that the
problem would also manifest on Windows, and we know that Dscho runs
the tests regularly on Windows, so I changed my mind. I did consider
Travis but wasn't sure if it was testing on case-insensitive
filesystems.

Are you planning on submitting the test as a proper patch as follow-up
to [1]? I couldn't quite decide in which test script it should reside.

[1]: https://public-inbox.org/git/xmqqr2qlps7r@gitster.mtv.corp.google.com/

Re: git 2.16.0 segfaults on clone of specific repo

[brian m. carlson]

On Fri, Jan 19, 2018 at 02:40:02AM -0500, Eric Sunshine wrote:
> 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 --stdint=$(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 ---

I'd argue that it's a worthwhile test to have, since it will fail on
those systems where it's going to be a problem.  Furthermore, people do
run the tests (as does Travis) on case-insensitive file systems during
the development cycle, so if we break something in the future, someone
will notice while we're still in the development cycle.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Re: git 2.16.0 segfaults on clone of specific repo

[Todd Zullinger]

Eric Sunshine wrote:
> 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.

The CASE_INSENSITIVE_FS prereq could be used to avoid
running the test on systems where it won't provide much
value, couldn't it?

> --- >8 ---
> hex2oct() {
>   perl -ne 'printf "\\%03o", hex for /../g'
> }
> 
> test_expect_success 'clone on case-insensitive fs' '
>   o=$(git hash-object -w --stdint=$(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)

-- 
Todd
~~
Money frees you from doing things you dislike. Since I dislike doing
nearly everything, money is handy.
-- Groucho Marx

Re: git 2.16.0 segfaults on clone of specific repo

[Eric Sunshine]

On Fri, Jan 19, 2018 at 3:22 AM, Duy Nguyen  wrote:
> On Fri, Jan 19, 2018 at 2:40 PM, Eric Sunshine  
> wrote:
>> On Fri, Jan 19, 2018 at 12:31:58PM +0700, Duy Nguyen wrote:
>>> 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.
> [...]
>> 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 ;-)

And, Dscho does run the test suite on Windows regularly, so perhaps
this test does have some practical value.

Re: git 2.16.0 segfaults on clone of specific repo

[Duy Nguyen]

On Fri, Jan 19, 2018 at 2:40 PM, Eric Sunshine  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  0x0055809f in is_empty_blob_sha1 (sha1=0x8fa6d4 "\236") at
cache.h:1055
#1  0x00558acd in ce_match_stat_basic (ce=0x8fa690,
st=0x7fffcd20) at read-cache.c:272
#2  0x00558c78 in ie_match_stat (istate=0x8e9fc0 ,
ce=0x8fa690, st=0x7fffcd20, options=5) at read-cache.c:342
#3  0x00501e01 in checkout_entry (ce=0x8fa690,
state=0x7fffcea0, topath=0x0) at entry.c:424
#4  0x005c8ea0 in check_updates (o=0x7fffd060) at unpack-trees.c:383
#5  0x005cb2bb in unpack_trees (len=1, t=0x7fffd010,
o=0x7fffd060) at unpack-trees.c:1382
#6  0x004214ca in checkout (submodule_progress=1) at builtin/clone.c:750
#7  0x004229ce in cmd_clone (argc=1, argv=0x7fffd840,
prefix=0x0) at builtin/clone.c:1191
#8  0x00405846 in run_builtin (p=0x89a908 ,
argc=2, argv=0x7fffd840) at git.c:346
#9  0x00405af7 in handle_builtin (argc=2, argv=0x7fffd840)
at git.c:554
#10 0x00405c8f in run_argv (argcp=0x7fffd6fc,
argv=0x7fffd6f0) at git.c:606
#11 0x00405e31 in cmd_main (argc=2, argv=0x7fffd840) at git.c:683
#12 0x004a3231 in main (argc=3, argv=0x7fffd838) 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

Re: git 2.16.0 segfaults on clone of specific repo

[Eric Sunshine]

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

(hex2oct lifted from t1007/t1450)

Re: git 2.16.0 segfaults on clone of specific repo

[Duy Nguyen]

On Fri, Jan 19, 2018 at 10:40 AM, brian m. carlson
 wrote:
> On Thu, Jan 18, 2018 at 10:06:10PM -0500, Eric Sunshine wrote:
>> > I have a guess about what the problem might be.  Can you try this patch
>> > and see if it fixes things?
>>
>> That does fix the crash. Thanks for the quick diagnosis.
>>
>> Can the commit message go into more detail as to why this was crashing
>> (or your speculation about why)? Perhaps give more detail about what
>> 'clone' is doing that led to the crash.
>
> Sure.  I ran into this as I was expanding the hash structure abstraction
> into my next series.  I'll send a follow-up patch with a more
> descriptive answer.
>
> 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've tried with gcc and
> two versions of clang, using -fno-lto, with address sanitizer, with -O0,
> and so on.  I'd really like to catch this kind of issue sooner in the
> future if I can figure out how to reproduce it.

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

vim-colorschemes.git has these two entries, which meets one of the
conditions, I suppose macos meets the other

colors/darkblue.vim
colors/darkBlue.vim

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

Re: git 2.16.0 segfaults on clone of specific repo

[brian m. carlson]

On Thu, Jan 18, 2018 at 10:06:10PM -0500, Eric Sunshine wrote:
> > I have a guess about what the problem might be.  Can you try this patch
> > and see if it fixes things?
> 
> That does fix the crash. Thanks for the quick diagnosis.
> 
> Can the commit message go into more detail as to why this was crashing
> (or your speculation about why)? Perhaps give more detail about what
> 'clone' is doing that led to the crash.

Sure.  I ran into this as I was expanding the hash structure abstraction
into my next series.  I'll send a follow-up patch with a more
descriptive answer.

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've tried with gcc and
two versions of clang, using -fno-lto, with address sanitizer, with -O0,
and so on.  I'd really like to catch this kind of issue sooner in the
future if I can figure out how to reproduce it.
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

RE: git 2.16.0 segfaults on clone of specific repo

[Randall S. Becker]

On January 18, 2018 10:06 PM, Eric Sunshine wrote:
> On Thu, Jan 18, 2018 at 9:47 PM, brian m. carlson
>  wrote:
> > On Thu, Jan 18, 2018 at 07:15:56PM -0500, Eric Sunshine wrote:
> >> On Thu, Jan 18, 2018 at 3:55 PM, Александр Булаев
> >>  wrote:
> >> > I found that git 2.16.0 segfaults on clone of vim-colorschemes repo.
> >>
> >> I can confirm that this crashes on MacOS; it does not crash on Linux or
> BSD.
> >>
> >> git-bisect places blame on eb0ccfd7f5 (Switch empty tree and blob
> >> lookups to use hash abstraction, 2017-11-12).
> >
> > I unfortunately don't have a macOS system to test with, and I've
> > compiled with both gcc and clang on my Debian system and, as you
> > mentioned, it doesn't fail there.
> >
> > I have a guess about what the problem might be.  Can you try this
> > patch and see if it fixes things?
> 
> That does fix the crash. Thanks for the quick diagnosis.
> 
> Can the commit message go into more detail as to why this was crashing (or
> your speculation about why)? Perhaps give more detail about what 'clone' is
> doing that led to the crash.

I'm curious as to why this worked on my platform, given how it tends to get 
annoyed with NULL in the wrong place.

> 
> > -- >8 --
> > From 10b690241619a452634b31fbc5ccd054a4f6e5ec Mon Sep 17 00:00:00
> 2001
> > From: "brian m. carlson" 
> > Date: Sun, 14 Jan 2018 18:26:29 +
> > Subject: [PATCH] repository: pre-initialize hash algo pointer
> >
> > There are various git subcommands (among them, clone) which don't set
> > up the repository but end up needing to have information about the
> > hash algorithm in use.  In the future, we can add a command line
> > option for this or read it from the configuration, but until we're
> > ready to expose that functionality to the user, simply initialize the
> > repository structure to use the current hash algorithm, SHA-1.
> >
> > Signed-off-by: brian m. carlson 
> > ---
> >  repository.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/repository.c b/repository.c index 998413b8bb..f66fcb1342
> > 100644
> > --- a/repository.c
> > +++ b/repository.c
> > @@ -5,7 +5,7 @@
> >
> >  /* The main repository */
> >  static struct repository the_repo = {
> > -   NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, _index,
> NULL, 0, 0
> > +   NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL,
> > + _index, _algos[GIT_HASH_SHA1], 0, 0
> >  };
> >  struct repository *the_repository = _repo;
> >
> > --

Re: git 2.16.0 segfaults on clone of specific repo

[Eric Sunshine]

On Thu, Jan 18, 2018 at 9:47 PM, brian m. carlson
 wrote:
> On Thu, Jan 18, 2018 at 07:15:56PM -0500, Eric Sunshine wrote:
>> On Thu, Jan 18, 2018 at 3:55 PM, Александр Булаев
>>  wrote:
>> > I found that git 2.16.0 segfaults on clone of vim-colorschemes repo.
>>
>> I can confirm that this crashes on MacOS; it does not crash on Linux or BSD.
>>
>> git-bisect places blame on eb0ccfd7f5 (Switch empty tree and blob
>> lookups to use hash abstraction, 2017-11-12).
>
> I unfortunately don't have a macOS system to test with, and I've
> compiled with both gcc and clang on my Debian system and, as you
> mentioned, it doesn't fail there.
>
> I have a guess about what the problem might be.  Can you try this patch
> and see if it fixes things?

That does fix the crash. Thanks for the quick diagnosis.

Can the commit message go into more detail as to why this was crashing
(or your speculation about why)? Perhaps give more detail about what
'clone' is doing that led to the crash.

> -- >8 --
> From 10b690241619a452634b31fbc5ccd054a4f6e5ec Mon Sep 17 00:00:00 2001
> From: "brian m. carlson" 
> Date: Sun, 14 Jan 2018 18:26:29 +
> Subject: [PATCH] repository: pre-initialize hash algo pointer
>
> There are various git subcommands (among them, clone) which don't set up
> the repository but end up needing to have information about the hash
> algorithm in use.  In the future, we can add a command line option for
> this or read it from the configuration, but until we're ready to expose
> that functionality to the user, simply initialize the repository
> structure to use the current hash algorithm, SHA-1.
>
> Signed-off-by: brian m. carlson 
> ---
>  repository.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/repository.c b/repository.c
> index 998413b8bb..f66fcb1342 100644
> --- a/repository.c
> +++ b/repository.c
> @@ -5,7 +5,7 @@
>
>  /* The main repository */
>  static struct repository the_repo = {
> -   NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, _index, 
> NULL, 0, 0
> +   NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, _index, 
> _algos[GIT_HASH_SHA1], 0, 0
>  };
>  struct repository *the_repository = _repo;
>
> --

Re: git 2.16.0 segfaults on clone of specific repo

[brian m. carlson]

On Thu, Jan 18, 2018 at 07:15:56PM -0500, Eric Sunshine wrote:
> [+cc:brian]
> 
> On Thu, Jan 18, 2018 at 3:55 PM, Александр Булаев
>  wrote:
> > I found that git 2.16.0 segfaults on clone of vim-colorschemes repo.
> >
> > (lldb) run
> > Process 25643 launched: '/usr/local/bin/git' (x86_64)
> > Cloning into 'vim-colorschemes'...
> > remote: Counting objects: 1457, done.
> > remote: Total 1457 (delta 0), reused 0 (delta 0), pack-reused 1457
> > Receiving objects: 100% (1457/1457), 1.43 MiB | 289.00 KiB/s, done.
> > Resolving deltas: 100% (424/424), done.
> > Process 25643 stopped
> > * thread #1, queue = 'com.apple.main-thread', stop reason =
> > EXC_BAD_ACCESS (code=1, address=0x48)
> 
> I can confirm that this crashes on MacOS; it does not crash on Linux or BSD.
> 
> git-bisect places blame on eb0ccfd7f5 (Switch empty tree and blob
> lookups to use hash abstraction, 2017-11-12).

I unfortunately don't have a macOS system to test with, and I've
compiled with both gcc and clang on my Debian system and, as you
mentioned, it doesn't fail there.

I have a guess about what the problem might be.  Can you try this patch
and see if it fixes things?

-- >8 --
From 10b690241619a452634b31fbc5ccd054a4f6e5ec Mon Sep 17 00:00:00 2001
From: "brian m. carlson" 
Date: Sun, 14 Jan 2018 18:26:29 +
Subject: [PATCH] repository: pre-initialize hash algo pointer

There are various git subcommands (among them, clone) which don't set up
the repository but end up needing to have information about the hash
algorithm in use.  In the future, we can add a command line option for
this or read it from the configuration, but until we're ready to expose
that functionality to the user, simply initialize the repository
structure to use the current hash algorithm, SHA-1.

Signed-off-by: brian m. carlson 
---
 repository.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/repository.c b/repository.c
index 998413b8bb..f66fcb1342 100644
--- a/repository.c
+++ b/repository.c
@@ -5,7 +5,7 @@
 
 /* The main repository */
 static struct repository the_repo = {
-   NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, _index, NULL, 
0, 0
+   NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, _index, 
_algos[GIT_HASH_SHA1], 0, 0
 };
 struct repository *the_repository = _repo;
 
-- 
2.16.0.rc2.280.g09355b536d
-- >8 --
-- 
brian m. carlson / brian with sandals: Houston, Texas, US
https://www.crustytoothpaste.net/~bmc | My opinion only
OpenPGP: https://keybase.io/bk2204


signature.asc
Description: PGP signature

Re: git 2.16.0 segfaults on clone of specific repo

[Eric Sunshine]

[+cc:brian]

On Thu, Jan 18, 2018 at 3:55 PM, Александр Булаев
 wrote:
> I found that git 2.16.0 segfaults on clone of vim-colorschemes repo.
>
> (lldb) run
> Process 25643 launched: '/usr/local/bin/git' (x86_64)
> Cloning into 'vim-colorschemes'...
> remote: Counting objects: 1457, done.
> remote: Total 1457 (delta 0), reused 0 (delta 0), pack-reused 1457
> Receiving objects: 100% (1457/1457), 1.43 MiB | 289.00 KiB/s, done.
> Resolving deltas: 100% (424/424), done.
> Process 25643 stopped
> * thread #1, queue = 'com.apple.main-thread', stop reason =
> EXC_BAD_ACCESS (code=1, address=0x48)

I can confirm that this crashes on MacOS; it does not crash on Linux or BSD.

git-bisect places blame on eb0ccfd7f5 (Switch empty tree and blob
lookups to use hash abstraction, 2017-11-12).

RE: git 2.16.0 segfaults on clone of specific repo

[Randall S. Becker]

On January 18, 2018 3:56 PM, Aleks wrote:
> I found that git 2.16.0 segfaults on clone of vim-colorschemes repo.


Just tested on NonStop NSE and works fine here. Just an FYI now that we're on 
2.16.0.

Cheers,
Randall

-- Brief whoami:
  NonStop developer since approximately NonStop(2112884442)
  UNIX developer since approximately 421664400
-- In my real life, I talk too much.

git 2.16.0 segfaults on clone of specific repo

[Александр Булаев]

I found that git 2.16.0 segfaults on clone of vim-colorschemes repo.
See the log below.

alexbool@alexbool-osx ~/Documents> lldb -- git clone
https://github.com/flazz/vim-colorschemes.git
(lldb) target create "git"
Current executable set to 'git' (x86_64).
(lldb) settings set -- target.run-args  "clone"
"https://github.com/flazz/vim-colorschemes.git;
(lldb) run
Process 25643 launched: '/usr/local/bin/git' (x86_64)
Cloning into 'vim-colorschemes'...
remote: Counting objects: 1457, done.
remote: Total 1457 (delta 0), reused 0 (delta 0), pack-reused 1457
Receiving objects: 100% (1457/1457), 1.43 MiB | 289.00 KiB/s, done.
Resolving deltas: 100% (424/424), done.
Process 25643 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=1, address=0x48)
frame #0: 0x0001000f7c3d git`ce_match_stat_basic + 263
git`ce_match_stat_basic:
->  0x1000f7c3d <+263>: movq   0x48(%rax), %rsi
0x1000f7c41 <+267>: movl   $0x14, %edx
0x1000f7c46 <+272>: movq   %r14, %rdi
0x1000f7c49 <+275>: callq  0x1001659fa   ; symbol stub
for: memcmp
Target 0: (git) stopped.
(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason =
EXC_BAD_ACCESS (code=1, address=0x48)
  * frame #0: 0x0001000f7c3d git`ce_match_stat_basic + 263
frame #1: 0x0001000f7ae8 git`ie_match_stat + 108
frame #2: 0x0001000bbe07 git`checkout_entry + 266
frame #3: 0x000100144ff9 git`unpack_trees + 2317
frame #4: 0x000100017e13 git`cmd_clone + 5733
frame #5: 0x00011ea3 git`handle_builtin + 532
frame #6: 0x00011954 git`cmd_main + 263
frame #7: 0x000100079a28 git`main + 80
frame #8: 0x7fff64d76115 libdyld.dylib`start + 1
(lldb) ^D
alexbool@alexbool-osx ~/Documents> git --version
git version 2.16.0

OS: macOS 10.13.2
git installed from homebrew