git stash save on 64-bit fails with Cannot save the current worktree state

[MikeDimmickMnetics]

• [x] 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.13.3.windows.1
built from commit: faaf2320f32f6ac52a69502c6b157b6ea4781f50
sizeof-long: 4
machine: x86_64

Also reproduces with 2.17.0

git version 2.17.0.windows.1
cpu: x86_64
built from commit: e7621d891d081acff6acd1f0ba6ae0adce06dd09
sizeof-long: 4

This issue does not reproduce with 32-bit versions.

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

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

# One of the following:
$ cat /etc/install-options.txt

Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Disabled
Enable Symlinks: Disabled

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

None.

Details

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

Reproduces in Bash, CMD and PowerShell

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

$ mkdir stash-test
$ cd stash-test
$ git init
$ echo test > test.txt
$ git add .
$ git commit -m "Test"
$ echo test >> test.txt
$ git add .
$ git stash save

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

A new stash to be created containing the change to test.txt

• What actually happened instead?

git stash save fails with the error

Cannot save the current worktree state

Nothing else is logged. A sh.exe.stackdump file is created in the current working directory with this content (from 2.13.3):

Exception: STATUS_STACK_OVERFLOW at rip=7FFCD7729F97
rax=0000000000000010 rbx=0000000000000000 rcx=0000000000000010
rdx=000000000000000C rsi=000000000000014C rdi=00007FFCCEE7D4F0
r8 =00000000C0000023 r9 =00000000FFFFA9C0 r10=00000000FFFFA000
r11=00000000FFE03E00 r12=00000000FFFFB500 r13=000000000016EE60
r14=00000000FFFFAA50 r15=0000000000000000
rbp=00000000FFFFA9C0 rsp=00000000FFFFA978
program=C:\Program Files\Git\usr\bin\sh.exe, pid 4596, thread unknown (0x12C8)
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame        Function    Args
000FFFFA9C0  7FFCD7729F97 (00000000104, 000FFFFAA38, 7FFCD7705278, 00000000000)
000FFFFA9C0  7FFCD7704938 (7FFCCEE7D4F0, 7FFCCEE7D4F0, 00000000001, 00000230022)
000FFFFAA38  7FFCD3D77E14 (7FFCD7680000, 7FFCD77048A0, 7FFCD76EB430, 7FFFFFFEFFFF)
000FFFFAC00  7FFCD3D77C95 (3C03000600010000, 64B0A6D2767B, 00000000023, 000FFFFAD28)
000FFFFAC00  7FFCD3D77AF4 (7FFCCEE7D700, 00000000000, 00000000000, 7FFCCEE7D700)
000FFFFAC00  7FFCCEDE03A0 (000FFFFAC00, 000FFFFAD28, 000001052B0, 00000000000)
000FFFFAC00  7FFCCEDB37DB (000FFFFB530, 00000000000, 000FFFFB8E0, 000001052B0)
000FFFFB369  7FFCCED8E4D0 (00000000000, 00000000000, 7FFCD76B0F20, 00180010018)
00180010018  7FFCCED8CFDD (00000000000, 000FFFFB690, 00000000000, 000FFFFB730)
000FFFFB690  7FFCCED85543 (000FFFFB800, 000000001C8, 00000000000, 0018026E740)
00000000420  7FFCD3DB7BD6 (00000000001, 00000000000, 000FFFFB8E0, 00100000001)
00000000420  7FFCD58ABA83 (00000000020, 00000000000, 000FFFFBA60, 00000000001)
00000000420  001800A9EA2 (000FFFFBA00, 00000000000, 7FFC00000000, 00000000000)
000FFFFBA80  001800AAA45 (00100410FBB, 00000000001, 006000520C0, 001004E6740)
000FFFFBC80  0018011A58B (00100410FBB, 00000000001, 006000520C0, 001004E6740)
000FFFFBC80  00000E3E458 (00100410FBB, 00000000001, 006000520C0, 001004E6740)
End of stack trace (more stack frames may be present)

Other git stash commands (e.g. list) seem to work, but they still cause sh.exe.stackdump to be created.

git stash push is not a viable alternative as my main GUI tool, GitExtensions, hasn't yet learned it. When run from the command line, git stash push creates the stash, but still causes the stack dump.

[MikeDimmickMnetics]

On a clean virtual machine with Windows 10 Fall Creators Update (1709, including updates to Dec 2017), the problem does not reproduce.

> cmd /c ver

Microsoft Windows [Version 10.0.16299.125]

After applying the April 2018 Cumulative Update, the problem still does not reproduce.

Unfortunately our system administrator hasn't yet approved version 1709 for my host OS, so I can't solve the problem that way.

[dscho]

Do you have Comodo Internet Security running, or a similar anti-malware, perchance?

[MikeDimmickMnetics]

Sophos Endpoint Security and Control. Agent version 2.0.2, Endpoint Advanced version 10.8.1.1.

[dscho]

That might be the culprit here. We are constantly haunted by anti-malware triggering by mistake on our fork of the Cygwin runtime, which is needed to execute Unix shell scripts (and git stash is implemented as such).

The bad news: don't hold your breath for a fix. This won't be resolved over night.

The good news: we have a Google Summer of Code project dedicated to converting git stash to a builtin in regular, portable C. Your issue should be side-stepped nicely by this conversion.

[dscho]

(If you want to follow this project, read this mail and keep your eyes open for more coming from the same direction.)

[jcberthon]

Hi @dscho

It seems that you have a fix for that: see commit in MSYS2: https://github.com/git-for-windows/msys2-runtime/commit/36e86e52805541f284fdab489821d6571f5806d0.

According to the cygwin mailing list, this should fix many bugs related to stack overflow. Those bugs were exacerbated by the presence of injected DLLs such as those from antimalware solution.

Question: when this MSYS2 commit will be part of a Git for Windows release?

[dscho]

Question: when this MSYS2 commit will be part of a Git for Windows release?

Answer: with the next Git for Windows version, most likely v2.19.0, to follow Git v2.19.0 (probably on September 10th, see: http://tinyurl.com/gitCal).

You can verify whether this issue is fixed by testing https://github.com/git-for-windows/git/releases/v2.19.0-rc0.windows.1

[MikeDimmickMnetics]

I reproduced the problem just now with v2.18.0.windows.1. After installing v2.19.0-rc0.windows.1, I can no longer reproduce the problem. Looks like this one is fixed.

My company's IT department installs HitmanPro.Alert, the component mentioned on the cygwin mailing list. That's probably why it reproduced for me and not for others.

[dscho]

@MikeDimmickMnetics did you choose the builtin stash in the Experimental Options installer page?

[MikeDimmickMnetics]

@dscho I don't recall that being an option for v2.19.0-rc0.windows.1. /etc/install-options.txt has:

Editor Option: VisualStudioCode
Path Option: Cmd
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFAlways
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Disabled
Enable Symlinks: Disabled

I looked carefully at the available releases before picking one to install; I opted for rc0.windows.1 because the built-in stash was not mentioned, unlike rc0.windows.2 and (I assumed) rc1.

I've just reinstalled and was not asked about using builtin stash or rebase.

[dscho]

I don't recall that being an option for v2.19.0-rc0.windows.1

You are correct!

v2.19.0-rc1.windows.1 has it, and it defaults to the non-built-in stash, so you should be safe by default. However, in your case, "safe" is not what you want, as it did not work for you previously ;-)

In any case, I am glad that you provided another data point in favor of that MSYS2 runtime fix, and I would like to encourage you to test the built-in stash which will side-step that fix, and be a lot faster. In my tests, it was around 90% faster!