Git Bash enters a crash-loop hang on startup

[kevinushey]

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

Using the 64-bit build.

$ git --version --build-options
git version 2.43.0.windows.1
cpu: x86_64
built from commit: 4b968f3ea3b32a7bc50846bab49f3f381841d297
sizeof-long: 4
sizeof-size_t: 8
shell-path: /bin/sh
feature: fsmonitor--daemon

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

This is an aarch64 build of Windows, running in a Parallels VM on an M1 macOS machine.

Edition	Windows 11 Pro
Version	24H2
Installed on	‎2/‎10/‎2024
OS build	26052.1000
Experience	Windows Feature Experience Pack 1000.26052.1000.0

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

> type "C:\Program Files\Git\etc\install-options.txt"
Editor Option: VIM
Custom Editor Path:
Default Branch Option:
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: Enabled
Performance Tweaks FSCache: Enabled
Enable Symlinks: Disabled
Enable Pseudo Console Support: Disabled
Enable FSMonitor: Disabled

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

Git for Windows was working without issue previously, so I suspect something may have changed in the latest Windows Insider builds that is causing trouble here.

When I attach to the process with gdb, I see the following:

Thread 1 received signal SIGSEGV, Segmentation fault.
0x00000002101eeaf3 in memmem () from C:\Program Files\Git\usr\bin\msys-2.0.dll
(gdb) bt
#0  0x00000002101eeaf3 in memmem () from C:\Program Files\Git\usr\bin\msys-2.0.dll
#1  0x0000000210095d91 in cwdstuff::override_win32_cwd(bool, unsigned int) ()
   from C:\Program Files\Git\usr\bin\msys-2.0.dll
#2  0x000000021009642e in cwdstuff::set(path_conv*, char const*) () from C:\Program Files\Git\usr\bin\msys-2.0.dll
#3  0x0000000210047025 in dll_crt0_1(void*) () from C:\Program Files\Git\usr\bin\msys-2.0.dll
#4  0x0000000210045c86 in _cygtls::call2(unsigned int (*)(void*, void*), void*, void*) ()
   from C:\Program Files\Git\usr\bin\msys-2.0.dll
#5  0x0000000210045d34 in _cygtls::call(unsigned int (*)(void*, void*), void*) ()
   from C:\Program Files\Git\usr\bin\msys-2.0.dll
#6  0x0000000000000000 in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)

Is there anything else that's useful that I could provide? Note that I can successfully invoke git.exe from cmd.exe shell, so I suspect the issue is unique to the Git Bash shell.

Details

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

Using the default Git Bash shell.

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

This reproduces just when attempting to start Git Bash -- here, when clicking on the icon in my taskbar.

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

No busy-hang.

• What actually happened instead?

Busy-hang.

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

N/A

[dscho]

The MSYS2 runtime code hails from Cygwin. Is this also happening with regular Cygwin?

[kevinushey]

Hmm... For me, the Cygwin installer gets stuck trying to run the /etc/postinstall/0p_000_autorebase.dash script, seemingly with the same symptoms as I'm seeing in this issue (dash.exe stuck at 100% CPU). I wasn't able to attach gdb but WinDbg was able to get:

0:000> ~ k
 #   Arch   Child-SP          RetAddr               Call Site
00    AMD64 00000007`ffffc930 00007ffa`2a0a028f     cygwin1!memmem+0xcb
01    AMD64 00000007`ffffca90 00007ffa`2a0a0a49     cygwin1!cygwin_split_path+0x3a0
02    AMD64 00000007`ffffcb20 00007ffa`2a057071     cygwin1!cygwin_split_path+0xb5a
03    AMD64 00000007`ffffcc50 00007ffa`2a055e08     cygwin1!cygwin_dll_init+0x26b
04    AMD64 00000007`ffffcd80 00007ffa`2a055e86     cygwin1!_assert+0x23f0
05    AMD64 00000007`ffffcdd0 00000000`00000000     cygwin1!_assert+0x246e

So perhaps an issue in Cygwin (caused by some change in the most recent Windows builds)?

[kevinushey]

I'm going to follow up on the Cygwin mailing lists now that I have a reproducible example independent of Git for Windows -- thanks for helping point me in the right direction.

[dscho]

@kevinushey would you mind circling back with a link once there is a mail thread? (I did not see anything related on the cygwin mailing list yet.)

[kevinushey]

Done; I just submitted to the mailing list here (https://inbox.sourceware.org/cygwin/CAJXgQP0ZpcQXON_oKbgE=S8Y-M=9+b00cZ6s4Het01TCTp3ajA@mail.gmail.com/T/#u) and provided a back-reference to this thread just in case.

[ArminG-MSFT]

I like to renew this issue. We as Microsoft discovered internally that this issue will return soon as a result of changes in the OS that will go to pre-release flighting.

To refresh everybody's mind: This issue is caused by AMD64 cygwin crashing when running on ARM64 when emulated. This is because cygwin performs an 'optimisation' where it tries to find some assembly code in ntdll.dll. That is highly unsupported and should not be done at all! Realy cygwin should just stop doing this. On AMD64 they sort of get away with it (often doesn't work, but doesn't crash) but looking for x64 assembly code in an ARM64EC ntdll.dll is not only going to fail, but can lead to crashes.

Accidental shifts in ntdll.dll earlier this year made the issue appear and a bit later disappear. New optimizations and code changes in ntdll.dll that will appear publicly soon, will cause the crash to come back.

Fortunately cygwin already made a fix by not doing this scanning when running on ARM64 emulated. After all, you'll never find the correct x64 assembly sequence anyway when running on ARM64. However, it seems Git has not pulled over this fix yet. If so, it is essential Git will do this ASAP to prevent crashes in the future.

Fix here: cygwin/cygwin@4e77fa9

Latest version 2.47.0.2 installer is affected and will start crashing soon on ARM64 if not fixed. We may be able to delay the code changes from going out for a while, but we really need Git to help pull this fix in.

[ArminG-MSFT]

I didn't see this issue was closed, so I've posted a new bug report here: #5239