2.12.2: `git status` crashes in repository with long paths #1111

bturner · 2017-03-27T21:47:29Z

I was not able to find an open or closed issue matching what I'm seeing

Setup

Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git version --build-options
git version 2.12.2.windows.1
built from commit: 212247dd6345c820deeae61fcdf2f10cea10525a
sizeof-long: 4
machine: x86_64

Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

$ cmd.exe /c ver
Microsoft Windows [Version 10.0.14393]

What options did you set as part of the installation? Or did you choose the
defaults?

Path Option: Cmd
SSH Option: OpenSSH
CURL Option: WinSSL
CRLF Option: LFOnly
Bash Terminal Option: ConHost
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

I'll note that I've also reinstalled with CURL Option: OpenSSL and the crash remains.

Any other interesting things about your environment that might be related
to the issue you're seeing?

The repository in question (URL provided at the end) has some very long paths. When the zip is unpacked to a "deep" directory, git status writes several lines like these:

ChangeSet/Another folder 0/Another folder 1/Another folder 2/Another folder 3/Another folder 4/Another folder 5/Another folder 6/Another folder 7/file9.txt: Filename too long
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus vitae erat vitae augue consequat cursus. Nunc a ipsum erat, mattis aliquet ante/dir0/dir1/dir2/dir3/dir4/dir5/file1.txt: Filename too long
Lorem ipsum dolor sit amet, consectetur adipiscing elit. Phasellus vitae erat vitae augue consequat cursus. Nunc a ipsum erat, mattis aliquet ante/file1.txt: Filename too long

If I move it to a shorter path, like C:\Temp\a, these messages go away. With or without these "Filename too long" messages, git status still crashes at the end.

I have many other Git repositories, both bare and "normal" and git status runs without issue in them.

Details

Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

cmd, Git Bash via cmd

What commands did you run to trigger this issue? If you can provide a
Minimal, Complete, and Verifiable example
this will help us understand the issue.

git status

What did you expect to occur after running these commands?

Status output

What actually happened instead?

Git crashes with an access violation (seen in cmd) or a segmentation fault (seen from Git Bash, running in cmd).

If the problem was occurring with a specific repository, can you provide the
URL to that repository to help us with testing?

status-crash.zip

Unpack anywhere and run git status.

On Git 2.12.2, git status crashes
On Git 2.12.1, git status runs without issue, listing a lot of deleted files with nothing staged for commit (the expected results)

The text was updated successfully, but these errors were encountered:

jbuchberger · 2017-03-28T13:33:15Z

FWIW, I also observe failures upon git status, since installing 2.12.2 today. It only happens in one repository, where checkout contains long paths. As before, I use 64bit version. OS is win 8.1
Same output on both bash commands and win cmd: Segmentation fault

When uninstalling and using 2.12.1 instead, everything is fine again.

bturner · 2017-03-28T18:22:33Z

I think I don't see the "Segmentation fault" output when I'm running from cmd because I have Visual Studio 2017 installed, and its crash handler intercepts the crash when running from cmd and asks if I want to debug (which doesn't accomplish much since the release build of Git for Windows doesn't have any debug symbols).

Thadir · 2017-03-28T19:37:08Z

I have a simular problem it seems with this git version and my IDEA. Witch points to this.

konste · 2017-03-28T23:28:57Z

We have a repo where "git status" after particular branch is checked out immediately causes "Segmentation fault" error. Of course the repo is huge and very much private, so I cannot publish it as a repro for the bug. 2.12.1 does not expose that problem. We'll try to debug it on our end, but we only have Microsoft stack devs around here and don't know how to build debug version of Git from sources. If somebody could help us with the version which does debug memory allocations and as much tracing as possible we can run it against our repo and send back the results.

laudukang · 2017-03-29T09:06:37Z

Same bug in Microsoft Windows [Version 10.0.15063] (MINGW64、IDEA 2017.1) with git 2.12.1 version, install 2.11.1 resolved

cs96and · 2017-03-29T14:08:10Z

I'm also seeing this issue. Additionally, viewing the log using TortoiseGit would report "Failed to get UnRevFileList". Reverting to 2.12.1 fixed both the "git status" and Tortoise log issues.

tpaxatb · 2017-03-29T20:16:26Z

I don't know if this is the problem but I am getting this in some repos but not others.

In name-hash.c, handle_range_dir(), the line
if (strncmp(istate->cache[k_start + 1]->name, prefix->buf, prefix->len) > 0)
k = k_start + 1;
fails because it appears there is a buffer overrun. The value of istate.cache[k_start + 1] is invalid. k_start is 10073. k_end is 10074. the cache only seems to have 10074 valid entries (the initial call to handle_range_1 from lazy_dir_thread_proc, the d->istate.cache_nr == 10074), and istate.cache[k_start + 1] is invalid?

theonicolaou · 2017-03-30T09:11:52Z

I don't get a crash but I am getting a "Segmentation fault" error in only one repo. I am on Windows 10, it's a new machine which I installed Git for Windows 64-bit on (git --version = 2.12.2.windows.1) all with default settings.

If you need any more info please let me know.

rafarah · 2017-03-30T23:42:42Z

As reported by Konste above, we've been debugging this issue, unfortunately with no symbols.
We are reproducing the issue using our Windows 10 machines.

Our findings are very similar to tpaxatb above:

strncmp() causes an Access Violation because the source address is invalid. First argument is null + offset, so it is 0x58 instead of + 0x58.

The strncmp is using:
strncmp(0x58 (invalid address!), “~/”, 2)

First argument: 0x58
Second argument: "~/"
Third argument: 2

The call stack is not very helpful since we don't have GIT symbols:

Just in case, we enabled Full Page Heap.
Below are the highlights of our technical details. We have more details if needed.

ANALYSIS

After some reverse engineering, frame 2 seems to be related to handle_range_dir() and frame 1 seems to be related to handle_range_1(), specifically this line:

static int handle_range_1(
struct index_state *istate,
int k_start,
int k_end,
struct dir_entry *parent,
struct strbuf *prefix,
struct lazy_entry *lazy_entries)
{
int input_prefix_len = prefix->len;
int k = k_start;

while (k < k_end) {
	struct cache_entry *ce_k = istate->cache[k];
	const char *name, *slash;

	if (prefix->len && strncmp(ce_k->name, prefix->buf, prefix->len))  <<< Here! #####
		break;

	name = ce_k->name + prefix->len;
	slash = strchr(name, '/');

frame 0 is stncmp() frame 2 has the content below, which pointed us to handle_range_dir():

0000000001118BB7
jmp git.11189A9

0000000001118BBC
lea rcx,qword ptr ds:[12016B7]
12016B7:"cache entry out of order" <<<
0000000001118BC3
call <git.sub_118A890>

0000000001118BC8
lea rcx,qword ptr ds:[12016D0]
12016D0:"BUG: strbuf_setlen() beyond buffer" <<<
0000000001118BCF
call <git.sub_118A890>

0000000001118BD4
lea rcx,qword ptr ds:[1201698]
1201698:"size_t overflow: %I64u + %I64u" <<<
0000000001118BDB
mov r8,r12

0000000001118BDE
mov edx,20
20:' '
0000000001118BE3
call <git.sub_118A890>

0000000001118BE8
call <git.__stack_chk_fail>

0000000001118BED
lea rcx,qword ptr ds:[1201698]
1201698:"size_t overflow: %I64u + %I64u" <<<
0000000001118BF4
mov r8d,1

0000000001118B6E
nop

0000000001118B70
lea rdx,qword ptr ds:[1201650]
1201650:"name-hash.c" <<<
0000000001118B77
lea rcx,qword ptr ds:[1201660]
1201660:"(parent != NULL) ^ (strchr(prefix->buf, '/') == NULL)" <<<
0000000001118B7E
mov r8d,112

0000000001118B84
call git.11C0A10

0000000001118B89
mov rbp,qword ptr ds:[r15+8]

0000000001118B8D
mov rdi,qword ptr ds:[r15+10]
rdi:"~~/", [r15+10]:"~~/" <<<
0000000001118B91
jmp git.1118880

0000000001118B96
nop word ptr cs:[rax+rax]

0000000001118BA0
mov edx,dword ptr ss:[rbp+3C]

0000000001118BA3
mov rcx,rdi
rdi:"~/"
0000000001118BA6
call git.11042B0

0000000001118BAB
mov dword ptr ds:[r12+C],eax

0000000001118BB0
jmp git.111898B

0000000001118BB5
xor eax,eax

frame 1 has this:

00000000011186DD mov rdx,qword ptr ss:[rsp+38]
00000000011186E2 mov rax,qword ptr ds:[r15+8]
00000000011186E6 mov rdi,qword ptr ds:[r15+10] rdi:"~~/", [r15+10]:"~~/"
00000000011186EA mov r12,qword ptr ds:[rdx]
00000000011186ED mov r8,rax
00000000011186F0 mov rdx,rdi rdi:"~/" <<< 2nd argument of strncmp()
00000000011186F3 mov qword ptr ss:[rsp+48],rax
00000000011186F8 mov rcx,qword ptr ds:[r12+r14+8] <<< NULL
00000000011186FD add rcx,58 <<< 1st argument of strncmp()
0000000001118701 call <git.strncmp>
0000000001118706 test eax,eax
0000000001118708 jle git.1118A91

r9 000000002E985F68 "/Common/Access/Objects/Activation"
r14 = 0n131288 (offset)
r12 = 00000000082689D8

r14+r12+8 = 0 (null)
r14+r12 = "0" <<<If we remove the +8 it points to the character "0"

So r14+r12 = valid content
r14+r12+8 = null

Frame 0:

In 64 bits the arguments are passed using @rcx, @RDX, @r8 and @r9 from left to right.

So our strncmp() has:

@rcx = 0x58 (0n88)
@RDX = 000000002cfb0770 <<< "~/"
@r8 = 2

Exception:

ExceptionAddress: 00007ff840eaa439 (ntdll!strncmp+0x0000000000000049)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 0000000000000058
Attempt to read from address 0000000000000058

hklene · 2017-03-31T09:11:23Z

I'm seeing this bug in 2.12.2, downgrade to 2.12.1 resolves the segmentation fault.

My working copy does not have extraordinary long paths:

$ find | wc -L
154
$ pwd | wc -L
27

Reproduced on two machines with clones of the same repository.

kgybels · 2017-03-31T10:55:37Z

For people trying to debug this, have a look at Compiling Git with Visual Studio. The generated projects are for VS2015.

Thadir · 2017-04-03T11:30:39Z

Reverting back to the old 2.12.1 version and indeed the problem is solved.

dscho · 2017-04-03T13:01:03Z

I think this is resolved by 59b761d

dscho · 2017-04-03T14:06:44Z

I am currently uploading snapshots of 32-bit PortableGit, 64-bit PortableGit, 32-bit Git for Windows installer, and 64-bit Git for Windows installer. Could you please test at your convenience (probably using 64-bit PortableGit) that the commit I mentioned indeed fixes the issue?

Thadir · 2017-04-03T14:13:07Z

Ill test it right now (going to install it and test it on a huge repo with long paths in windows). I do not have debugging on so be warned.

cs96and · 2017-04-03T14:17:50Z

I tested the 64-bit portable version and "git status" and viewing the git log via Tortoise are both working fine now.

Thadir · 2017-04-03T14:21:13Z

No problems on my end. My IntelliJ intergration that was bugging out works fine now.

aeracode · 2017-04-03T14:56:40Z

Checked. Win7 64bit.
Previously, version 2.12.2 git.exe status, git-ls-files.exe ... crash (or "Segmentation fault")
Now, snapshot of "64-bit Git for Windows installer" works fine,

tpaxatb · 2017-04-03T16:45:33Z

This seems to have fixed the issue on my end too, especially with untracked files and large directory trees.

dscho · 2017-04-03T18:27:15Z

Wonderful, thanks for all the feedback! And thank you, @kewillf for fixing this bug!

konste · 2017-04-03T18:52:17Z

What's ETA for 2.12.3?

dscho · 2017-04-03T21:00:13Z

What's ETA for 2.12.3?

Your guess is as good as mine.

If you are asking about the next Git for Windows release, though: as soon as I can convince myself that there are no other, critical bugs lurking. I want to get this out before the end of this week.

konste · 2017-04-03T21:31:26Z

If you are asking about the next Git for Windows release

Yes, of course! It is going to be 2.12.3, isn't it?

dscho · 2017-04-03T22:26:04Z

It is going to be 2.12.3, isn't it?

No. The main part of Git for Windows' versions reflects the Git version on which it is based. It is unlikely that Git v2.12.3 will be released this week, but Git for Windows needs to be released to fix this problem (and a Git LFS related one we identified a couple of days ago). so it will most likely be v2.12.2(2).

konste · 2017-04-03T22:31:00Z

Ah, I got it now. Thanks for clarification. I keep pulling reins to prevent whole bunch of developers from upgrading their Git for Windows and need to know when I would be able to release it.

A potential crash in `git status` with lots of files [was fixed](git-for-windows/git#1111). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho · 2017-04-05T14:40:15Z

@konste expect v2.12.2(2) Real Soon Now.

dscho · 2017-04-05T22:41:23Z

@konste FYI v2.12.2(2) is available for download.

konste · 2017-04-05T22:47:59Z

@dscho Wow! It is even on Chocolatey already. Thank you for letting me know! I unleash all the devs waiting for it now.

bturner mentioned this issue Mar 27, 2017

Git status fails with submodules #1110

Closed

1 task

dscho mentioned this issue Apr 3, 2017

git add * crashes with a segmentation fault. Version 2.12.2 (most recent as of writing) #1115

Closed

1 task

dscho closed this as completed Apr 3, 2017

dscho added this to the v2.12.3 milestone Apr 3, 2017

dscho added a commit to git-for-windows/build-extra that referenced this issue Apr 4, 2017

Mention Bug Fix in release notes

72ad198

A potential crash in `git status` with lots of files [was fixed](git-for-windows/git#1111). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>

dscho mentioned this issue Apr 4, 2017

Git.exe 2.12.2.1 crashes #1125

Closed

1 task

jbialobr mentioned this issue Jul 7, 2017

SEG FAULT on every git operation. gitextensions/gitextensions#3804

Closed

default0 mentioned this issue Jan 28, 2020

"git status" crashes in repositories with long file paths #2494

Closed

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

2.12.2: `git status` crashes in repository with long paths #1111

2.12.2: `git status` crashes in repository with long paths #1111

bturner commented Mar 27, 2017 •

edited

Loading

jbuchberger commented Mar 28, 2017 •

edited

Loading

bturner commented Mar 28, 2017

Thadir commented Mar 28, 2017

konste commented Mar 28, 2017

laudukang commented Mar 29, 2017

cs96and commented Mar 29, 2017

tpaxatb commented Mar 29, 2017

theonicolaou commented Mar 30, 2017

rafarah commented Mar 30, 2017

hklene commented Mar 31, 2017

kgybels commented Mar 31, 2017

Thadir commented Apr 3, 2017

dscho commented Apr 3, 2017

dscho commented Apr 3, 2017

Thadir commented Apr 3, 2017

cs96and commented Apr 3, 2017

Thadir commented Apr 3, 2017

aeracode commented Apr 3, 2017

tpaxatb commented Apr 3, 2017

dscho commented Apr 3, 2017

konste commented Apr 3, 2017

dscho commented Apr 3, 2017

konste commented Apr 3, 2017

dscho commented Apr 3, 2017

konste commented Apr 3, 2017

dscho commented Apr 5, 2017

dscho commented Apr 5, 2017

konste commented Apr 5, 2017

2.12.2: git status crashes in repository with long paths #1111

2.12.2: git status crashes in repository with long paths #1111

Comments

bturner commented Mar 27, 2017 • edited Loading

Setup

Details

jbuchberger commented Mar 28, 2017 • edited Loading

bturner commented Mar 28, 2017

Thadir commented Mar 28, 2017

konste commented Mar 28, 2017

laudukang commented Mar 29, 2017

cs96and commented Mar 29, 2017

tpaxatb commented Mar 29, 2017

theonicolaou commented Mar 30, 2017

rafarah commented Mar 30, 2017

Call Site

hklene commented Mar 31, 2017

kgybels commented Mar 31, 2017

Thadir commented Apr 3, 2017

dscho commented Apr 3, 2017

dscho commented Apr 3, 2017

Thadir commented Apr 3, 2017

cs96and commented Apr 3, 2017

Thadir commented Apr 3, 2017

aeracode commented Apr 3, 2017

tpaxatb commented Apr 3, 2017

dscho commented Apr 3, 2017

konste commented Apr 3, 2017

dscho commented Apr 3, 2017

konste commented Apr 3, 2017

dscho commented Apr 3, 2017

konste commented Apr 3, 2017

dscho commented Apr 5, 2017

dscho commented Apr 5, 2017

konste commented Apr 5, 2017

2.12.2: `git status` crashes in repository with long paths #1111

2.12.2: `git status` crashes in repository with long paths #1111

bturner commented Mar 27, 2017 •

edited

Loading

jbuchberger commented Mar 28, 2017 •

edited

Loading