Get Exception when using command after update to 2.45.1

[seanmars]

• 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.45.1.windows.1
cpu: x86_64
built from commit: 965b16798dab6962ada5b0d8cf0dca68f385c448
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?

$ cmd.exe /c ver

Microsoft Windows [Version 6.1.7601] 64-bit

• 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"
> type "$env:USERPROFILE\AppData\Local\Programs\Git\etc\install-options.txt"
$ cat /etc/install-options.txt

** insert your machine's response here **

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

** insert your response here **

Details

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

** insert your response here **

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

show the status of the repository

• What actually happened instead?

Exception 0xc0000005 0x8 0x0 0x0
PC=0x0

runtime.asmstdcall()
        runtime/sys_windows_amd64.s:65 +0x75 fp=0x22fca0 sp=0x22fc80 pc=0x46cd35
rax     0x0
rbx     0xe64b20
rcx     0xeb9140
rdi     0x7fffffdd000
rsi     0x22fea0
rbp     0x22fde0
rsp     0x22fc78
r8      0x0
r9      0x22fee0
r10     0xe8aab8
r11     0x21
r12     0x22fec0
r13     0x1
r14     0xe64280
r15     0x0
rip     0x0
rflags  0x10293
cs      0x33
fs      0x53
gs      0x2b
fatal: the remote end hung up unexpectedly

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

** insert URL here **

[dscho]

** insert your response here **

That's unfortunately quite a lot of placeholders, and not much information to go on.

The fact that your report shows assembly code (which Git for Windows does not do) suggests that in particular the "Any other interesting things about your environment that might be related to the issue you're seeing?" section would probably benefit from a careful revisit.

[rimrul]

Could this be git lfs? Because Git for Windows 2.45.1 contains git lfs 3.5.1
which is built with go 1.21, which requires Windows 10 and seems to cause a very similar error message on older Windows versions.

[dscho]

Could this be git lfs? Because Git for Windows 2.45.1 contains git lfs 3.5.1
which is built with go 1.21, which requires Windows 10 and seems to cause a very similar error message on older Windows versions.

Good finding, adding more evidence to the fact that providing more information in bug reports is better than omitting it.

[mjcheetham]

Git for Windows 2.45.1 contains git lfs 3.5.1 which is git-lfs/git-lfs#5668, which requires golang/go#64622 (comment)

Sorry for a tangent, but just curious about what this means for the ability of something like GCM, that is also available bundled with Git for Windows like LFS, for it to drop Windows 7/8.x support?

[rimrul]

Sorry for a tangent, but just curious about what this means for the ability of something like GCM, that is also available bundled with Git for Windows like LFS, for it to drop Windows 7/8.x support?

Dropping support for Windows 7 and 8.0 is completely fine from our perspective as we're doing the same in the next feature release. As for Windows 8.1, we'd prefer if it stayed supported, but we have previously discussed redirecting Windows 8.1 users to the last supported standalone GCM installer and only providing bundled GCM for users on Windows 10 and newer.

The only remaining concern is whatever agreement exists with the Visual studio team.

[mjcheetham]

Right, I was just referencing that Git LFS 3.5.1 no longer working on Windows 8.1 (instead requiring 10+) is also a conflict in supportable components of GfW

[rimrul]

What's more of a problem for us is that we didn't notice it upfront and Git for Windows 2.45.2 is probably the last release supporting Windows 7 and 8 and shipped with that Git LFS version.

[dscho]

What's more of a problem for us is that we didn't notice it upfront and Git for Windows 2.45.2 is probably the last release supporting Windows 7 and 8 and shipped with that Git LFS version.

Indeed. If I had realized from the release notes that it dropped support for even some Windows 10 versions, I would not have integrated it into Git for Windows. But the release notes are really mum about this change, which leads me to believe that the Git LFS maintainers were unaware that the Go version upgrade would cause this.

[rimrul]

What's more of a problem for us is that we didn't notice it upfront and Git for Windows 2.45.2 is probably the last release supporting Windows 7 and 8 and shipped with that Git LFS version.

I'd like to not leave it like that. How do we want to resolve this? The simplest solution would be rolling back to 3.4.1, but that would lock users of newer Windows versions out of new features. One approach might be to keep a mingw-w64-git-lfs-3.4 package as an alternate for affected windows versions, kind of similar to our curl alternates. Another approach might be to try and build git-lfs from source with an older version of go, but we've avoided even building git-lfs from source with a supported vesion of go so far, so this might be a path we want to keep avoiding. Or we could point users of affected Windows versions to a standalone download of Git LFS.

Indeed. If I had realized from the release notes that it dropped support for even some Windows 10 versions,

Do you have a link for this? I can't seem to find any information about this.

[seanmars]

** insert your response here **

That's unfortunately quite a lot of placeholders, and not much information to go on.

The fact that your report shows assembly code (which Git for Windows does not do) suggests that in particular the "Any other interesting things about your environment that might be related to the issue you're seeing?" section would probably benefit from a careful revisit.

I'm sorry for not providing more information that I found useful, because the entire system only had problems with updating GfW, so I didn't think of other possible causes.

But now it seems that it may be because git-lfs updates the golang version, because I found that many people have raised errors related to golang that are very similar to my error message.

[dscho]

What's more of a problem for us is that we didn't notice it upfront and Git for Windows 2.45.2 is probably the last release supporting Windows 7 and 8 and shipped with that Git LFS version.

I'd like to not leave it like that.

@bk2204 @chrisd8088 any feedback from you kind Git LFS people? The issue is that Git LFS v3.5.1 dropped support for Windows versions before Windows 10. Any guidance how the Git LFS project wants to navigate this (so that Git for Windows may follow suite)?

[chrisd8088]

@bk2204 @chrisd8088 any feedback from you kind Git LFS people? The issue is that Git LFS v3.5.1 dropped support for Windows versions before Windows 10. Any guidance how the Git LFS project wants to navigate this (so that Git for Windows may follow suite)?

Hmm -- thanks for bringing this to our attention. I don't know that either of us was aware of this change in Windows support from the Go language upgrade.

Our policy has been to try to stay current with the latest Go version because their policy is to only provide support for the two most recent major versions. So if it's possible to align with the Windows 10+ requirement in Git for Windows more broadly, that would obviously be convenient for us.

If not, though, I suppose we could investigate building a custom release on an older Go version for a fixed period of time to help Git for Windows, but I think we'd want to know that time period was going to be as brief as possible.

[dscho]

@chrisd8088 Git for Windows carefully announced the pending end of support for Windows 7/8 for quite a while, but will have to support Windows 8.1 for now.

I only see a couple of inconvenient options going forward:

• drop Git LFS from Git for Windows, pointing users who need it to the download page of Git LFS.
• pin to an older Git LFS version
• have Git for Windows build Git LFS with an older Go version for every new Git LFS version.

Currently, my thinking is that the first option is the least bad.

[chrisd8088]

@dscho -- You should make whatever decision is best for the Git for Windows project, of course. If you want to build Git LFS with an older Go version, we could certainly collaborate to try to make that possible.

One other idea occurred to me: would you consider it a viable path forward if the installer process (either the Git for Windows installer, or the Git LFS installer) checked the Windows version and made a decision as to whether to install Git LFS based on that?