cmd\git.exe crashing when ARM64 folder is present in Git installation (git-wrapper)

[dennisameling]

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

denni@DESKTOP-8HTP3NV ARM64 /
$ git --version --build-options
git version 2.31.0.GIT
cpu: AMD64
no commit associated with this build
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh

• 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.19042.844]

Windows 10 ARM64

• 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: VisualStudioCode
Custom Editor Path:
Default Branch Option: main
Path Option: Cmd
SSH Option: OpenSSH
Tortoise Option: false
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Git Pull Behavior Option: Merge
Use Credential Manager: Core
Performance Tweaks FSCache: Enabled
Enable Symlinks: Enabled

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

See more details below

Details

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

CMD/PowerShell (Git Bash works correctly since it's not using cmd\git.exe).

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

• What did you expect to occur after running these commands?

the actual git version

• What actually happened instead?

program crashed

Attempt to debug with printf

I first added some printf statements to git-wrapper.c:

C:\Program Files (x86)\Git\cmd>.\git.exe version
Starting to check if running on ARM64...
Checking if arm64/bin exists...
arm64/bin seems to exist!
(crash)

So it seems to crash at the line wcscpy(msystem_bin, L"arm64/bin");:

https://github.com/git-for-windows/MINGW-packages/blob/e365c848ca812211f7118774d44ec1860ebaedba/mingw-w64-git/git-wrapper.c#L141_L142

Attempt to debug with gdb

⚠️ This is was first time to debug with gdb, following the steps at https://github.com/git-for-windows/git/wiki/Debugging-Git#debugging-crashes-segmentation-faults, let me know if I missed something.

I added a breakpoint to the wcscpy command mentioned above, and after it. Indeed looks like that's the culprit:

(gdb) r
Starting program: c:\Program Files (x86)\Git\cmd\git.exe 
[New Thread 15492.0x186c]
[New Thread 15492.0x4934]
[New Thread 15492.0x407c]
[Switching to thread 1 (Thread 15492.0x10b8)](running)

Thread 1 hit Breakpoint 3, is_running_on_arm64 (top_level_path=0x5089d20 L"C:\\Program Files (x86)\\Git\\arm64/bin", msystem_bin=0x0) at ../git-wrapper.c:151
151				wcscpy(msystem_bin, L"arm64/bin");
[New Thread 15492.0x1d2c]
[Thread 15492.0x4934 exited with code 3221226505]
[Thread 15492.0x407c exited with code 3221226505]
[Thread 15492.0x186c exited with code 3221226505]
[Thread 15492.0x1d2c exited with code 3221226505]
[Inferior 1 (process 15492) exited with code 030000002011]

Additional background

Please note that cmd\git.exe only crashes if running on ARM64 and an arm64/bin folder is present. Running ARM64 Git for Windows through Git Bash works without any issues, so the git-wrapper is most likely the issue here.

This is probably related to the change introduced in git-for-windows/MINGW-packages#46, but back then everything seemed to work, even when the arm64/bin folder was present. My apologies in case I tested incorrectly back then, I might simply have missed this bug.

Please let me know if I can provide additional context.

[dscho]

Oh, that's most likely because we pass NULL as msystem_bin: https://github.com/git-for-windows/MINGW-packages/blob/e365c848ca812211f7118774d44ec1860ebaedba/mingw-w64-git/git-wrapper.c#L800 🤦

[rimrul]

$ git --version --build-options
git version 2.31.0.GIT
cpu: AMD64
no commit associated with this build

That seems like we'll need to check that as well. If I understand the current state of Windows on ARM correctly, you shouldn't be able to execute an actual AMD64 build, so this command seems to output incorrect information.

[dscho]

That seems like we'll need to check that as well.

I think that's a shortcoming in the CMake-based build.

Oh, that's most likely because we pass NULL as msystem_bin: https://github.com/git-for-windows/MINGW-packages/blob/e365c848ca812211f7118774d44ec1860ebaedba/mingw-w64-git/git-wrapper.c#L800 🤦

I don't really have any time to investigate now, maybe you could follow the Blame to see whether we should not have passed NULL in the first place, or whether we should guard the wcscpy() behind an if (msystem_bin), @dennisameling ?

[rimrul]

I think that's a shortcoming in the CMake-based build.

The CMake build seems to set GIT_HOST_CPU and based on their documentation CMAKE_SYSTEM_PROCESSOR seems to be the correct value to use, but it should be set in a CMAKE_TOOLCHAIN_FILE when cross-compiling, which we apparently do not do.

git/contrib/buildsystems/CMakeLists.txt

Line 197 in 4321276

add_compile_definitions(GIT_HOST_CPU="${CMAKE_SYSTEM_PROCESSOR}")

[dscho]

@dennisameling re: the segmentation fault, can you see whether git-for-windows/MINGW-packages#47 fixes your issue?

[dscho]

it should be set in a CMAKE_TOOLCHAIN_FILE when cross-compiling, which we apparently do not do.

But we do, don't we? See

git/contrib/buildsystems/CMakeLists.txt

Line 64 in 4321276

set(CMAKE_TOOLCHAIN_FILE ${VCPKG_DIR}/scripts/buildsystems/vcpkg.cmake CACHE STRING "Vcpkg toolchain file")

Open

[rimrul]

But we do, don't we?

We specify a CMAKE_TOOLCHAIN_FILE, but that file doesn't seem to contain a single mention of CMAKE_SYSTEM_PROCESSOR. Which causes cmake to believe we're not cross-compiling for arm and set the wrong GIT_HOST_CPU.

[rimrul]

I think microsoft/vcpkg#16111 might fix that.