"git status" crashes in repositories with long file paths

[default0]

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

This was reported and fixed in #1111 but recently seems to have regressed.

Setup

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

64-bit, 2.25.0

$ git --version --build-options

git version 2.25.0.windows.1
cpu: x86_64
built from commit: 7c71c859c97853ed057da5cbab12f3c13b5554df
sizeof-long: 4
sizeof-size_t: 8

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

$ cmd.exe /c ver
Microsoft Windows [Version 10.0.18362.592]
(c) 2019 Microsoft Corporation. All rights reserved.

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

# One of the following:
> type "C:\Program Files\Git\etc\install-options.txt"
> type "C:\Program Files (x86)\Git\etc\install-options.txt"
> type "%USERPROFILE%\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

Editor Option: Notepad++
Custom Editor Path: 
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Disabled

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

See details

Details

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

Git Bash

• 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?

The status of the repository was shown

• What actually happened instead?

The command crashed and wrote "Illegal instruction" instead

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

I cannot provide a URL to the repository, however the issue is relating to long file paths.
The repository contains files with paths that exceed a length of 260 characters.
I have core.longpaths (or w/e the option was called) set to true, deleting all files in the repository that have filenames longer than 260 characters fixes the issue.

This is a regression from 2.24.1.2 because in that version, the same repository works just fine.

[dscho]

Please do spend an effort in creating an MCVE. For all I know, this could be caused by your CPU and not reproducible here at all.

[default0]

git config --system core.longpaths true
git clone https://github.com/default0/GitForWindowsBugRepro
cd GitForWindowsBugRepro
git status

You are welcome :-)

[rimrul]

The only thing that fails here is the checkout part of git clone.

[default0]

You need to set core.longpaths to true, as described in the Details of the issue

[dscho]

You need to set core.longpaths to true, as described in the Details of the issue

Where? @default0 you could really make this easier for the people you ask for help. Please do so.

[default0]

Added the entry to the first set of commands

[dscho]

I am offering you a service of letting you know about an issue introduced in a recent version of your product.

Okay, this is not going to work.

First of all, this is an open source project, not "your product".

Second of all, you are asking for help. Because like it or not, there will be another set of security fixes like in v2.24.1, and then you will be forced to upgrade, or stay vulnerable. So it is in your interest to have this fixed.

Further this attitude that you are doing others a favor by telling them what is wrong with their code that you are happily using without even saying thanks, this attitude is not friendly. We do want a friendly place over here, though, because otherwise everybody would have a foul time and the project would die.

So let's avoid that, okay?

[dscho]

Since this ticket took such an unpleasant turn, I will spend the rest of my work time today elsewhere.

[lexeek]

I faced the same issue on Windows 10 with the last version of GIT. Today I spent a lot of time trying to find a problem on my system and had despaired, then found this issue. As TS suggests above, I have downgraded git to v2.24.1 and now everything works fine.
HI @dscho, can you tell what I have to do to fix this problem with v2.5, or need to wait for a bug fix?

[dscho]

@lexeek an MCVE would be helpful: a small list of commands that initializes a new, tiny Git worktree and that reproduces the issue.

[lexeek]

@dscho Hm, I will try to emulate this error with a new git repo, but can't do it with the current project, the problem is the size of the repo more than 60Gb (C++ project with lots of models) and it takes time to reproduce.
I will try to analyze the team's last commits and probably find something helpful. A few days ago everything worked fine.

[dscho]

Sounds good. Thank you!

[henrik-m]

I see this problem too for one of our projects with long filepaths. The minimal repro posted by @default0 reproduces it for me as well.

$ git --version
git version 2.25.0.windows.1

$ git status
Illegal instruction

My OS:

Get-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, ServicePackMajorVersion, OSArchitecture

Caption                  Version    ServicePackMajorVersion OSArchitecture
-------                  -------    ----------------------- --------------
Microsoft Windows 10 Pro 10.0.18363                       0 64-Bit

[dscho]

The minimal repro posted by @default0 reproduces it for me as well.

@henrik-m unfortunately, it does not reproduce here, most likely because the repro is actually not complete: it assumes that you already have a repository/worktree with a certain shape, but it is totally unclear what that shape would be, so people like me (who would be quite capable of debugging this, given a complete repro) are set up to fail.

Therefore, if you can figure out an easy repro that is complete (i.e. that will reproduce the bug also on my machine), that would be quite helpful.

[henrik-m]

@dscho I managed to reproduce this on a fresh Azure cloud VM based on a public VM image. What I did:

1. Create a new Azure VM, based on the image "Windows 10 Pro, Version 1909" provided by Microsoft
2. Login via RDP, set all telemetry related settings to "off"
3. Install latest release (2.25.0) for Window from https://git-scm.com/ via wizard. I changed a few default options in the installer and activated long paths to match my work pc config, this is all reflected in the resulting gitconfig file in C:\Program Files\Git\etc:

[diff "astextplain"]
	textconv = astextplain
[filter "lfs"]
	clean = git-lfs clean -- %f
	smudge = git-lfs smudge -- %f
	process = git-lfs filter-process
	required = true
[http]
	sslBackend = schannel
[core]
	autocrlf = input
	fscache = true
	symlinks = true
	longpaths = true
[credential]
	helper = manager

4. Create folder C:\workspace
5. Open git bash in this folder and checkout the repo posted by @default0

git clone https://github.com/default0/GitForWindowsBugRepro

6. In git bash, run cd GitForWindowsBugRepro, git status => I get "Illegal instruction" as response

[dscho]

Excellent! Cloning now.

[dscho]

This is an outstanding MCVE, @henrik-m! Thank you:

$ git clone -c core.longpaths=true https://github.com/default0/GitForWindowsBugRepro
Cloning into 'GitForWindowsBugRepro'...
remote: Enumerating objects: 4190, done.
remote: Counting objects: 100% (4190/4190), done.
remote: Compressing objects: 100% (3015/3015), done.
remote: Total 4190 (delta 840), reused 4190 (delta 840), pack-reused 0
Receiving objects: 100% (4190/4190), 4.31 MiB | 1.39 MiB/s, done.
Resolving deltas: 100% (840/840), done.
Updating files: 100% (4180/4180), done.

$ cd GitForWindowsBugRepro/

$ git status
Illegal instruction

[dscho]

This was a little bit tricky to debug, as the symptom did not reproduce in debug builds, and even DrMemory (at least in the version I have over here) could not help diagnose it because it crashed with an internal bug.

The good news is that I think I found the culprit, and it was rather easy to fix. I put up a PR and will merge it as soon as the PR build passes (I deem it too obvious a fix to require a whole lot of reviews).

[henrik-m]

Nice! Thank you for addressing this so quickly.

[dscho]

@henrik-m @default0 could you test the latest snapshot, please?

[henrik-m]

@dscho Tested it on the cloud VM and then on my work PC where I originally encountered the problem. The error went away on both machines. Thank you very much!

[dscho]

@henrik-m thank you so much for speedy testing and quick responses!

[henrik-m]

I'm glad I could help.