Summary:
This Issue is in reference to a ticket that was filed with us in Visual Studio. However, we believe the underlying issue to be related to mismatched versions of MinGit/Git for Windows. I haven't been able to reproduce the issue myself, but there is a lot of good info provided by the affected user in the linked ticket that might make more sense here.
Duplicate info from Linked Ticket
Git for Windows includes a component that needs to be pinned in memory at a known location, so that the Unix-like shell that git bash uses can find it. Anything that moves the component – ASLR, rebasing due to address conflicts, etc. – will cause the component to stop working. The specific failure case here seems to be that when you’ve got multiple versions of Git for Windows installed of the same bitness, if that shared component DLL isn’t binary-identical across those versions, the second one that is loaded into memory will be automatically rebased and stop working.
The affected component is msys-2.0.dll, which is present at (for example):
C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\usr\bin for a typical Visual Studio installation; and
C:\Program Files\Git\usr\bin within a typical Git for Windows installation.
It seems that this problem may have started occurring when VS 2022 began to include 64-bit git components, at version 17.2.0. The problem is heavily dependent on the version of the Git for Windows installation that is side-by-side with VS 2022; with GfW 2.35.2 against VS 2022 17.2.0, the problem is reproducible. Updating VS 2022 to 17.2.7 moves its internal git installation to 2.37.1 and the problem appears to cease; however, it seems likely that further changes to either git installation could cause the problem to recur.
Any git operation taken from within Visual Studio in this state will fail with a base address mismatch in the MSYS component, with this output:
0 [main] which (4152) C:\Program Files\Git\usr\bin\which.exe: *** fatal error - cygheap base mismatch detected - 0x18034B408/0x180349408.
This problem is probably due to using incompatible versions of the cygwin DLL.
Search for cygwin1.dll using the Windows Start->Find/Search facility
and delete all but the most recent version. The most recent version *should*
reside in x:\cygwin\bin, where 'x' is the drive on which you have
installed the cygwin distribution. Rebooting is also suggested if you
are unable to find another cygwin DLL.
Questions
I haven't found any existing resources mentioning this happening with 64bit git. Does this sound like an expected scenario? Are there any workarounds besides ensuring that all git processes on the system are compatible versions of Git+msys2?
- [ 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? 64 bit
MinGit: 2.36.0
GfW: 2.35.2
- Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?
- What options did you set as part of the installation? Or did you choose the
defaults?
- Any other interesting things about your environment that might be related
to the issue you're seeing?
I can ask this in the linked ticket.
Details
-
Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other
GfW: unknown
MinGit: VS spawns git.exe process directly via Kernel32.CreateProcess
-
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.
seemingly occurs when GfW and MinGit load conflicting msys2 versions
Summary:
This Issue is in reference to a ticket that was filed with us in Visual Studio. However, we believe the underlying issue to be related to mismatched versions of MinGit/Git for Windows. I haven't been able to reproduce the issue myself, but there is a lot of good info provided by the affected user in the linked ticket that might make more sense here.
Duplicate info from Linked Ticket
Git for Windows includes a component that needs to be pinned in memory at a known location, so that the Unix-like shell that git bash uses can find it. Anything that moves the component – ASLR, rebasing due to address conflicts, etc. – will cause the component to stop working. The specific failure case here seems to be that when you’ve got multiple versions of Git for Windows installed of the same bitness, if that shared component DLL isn’t binary-identical across those versions, the second one that is loaded into memory will be automatically rebased and stop working.
The affected component is msys-2.0.dll, which is present at (for example):
C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Git\usr\binfor a typical Visual Studio installation; andC:\Program Files\Git\usr\binwithin a typical Git for Windows installation.It seems that this problem may have started occurring when VS 2022 began to include 64-bit git components, at version 17.2.0. The problem is heavily dependent on the version of the Git for Windows installation that is side-by-side with VS 2022; with GfW 2.35.2 against VS 2022 17.2.0, the problem is reproducible. Updating VS 2022 to 17.2.7 moves its internal git installation to 2.37.1 and the problem appears to cease; however, it seems likely that further changes to either git installation could cause the problem to recur.
Any git operation taken from within Visual Studio in this state will fail with a base address mismatch in the MSYS component, with this output:
Questions
I haven't found any existing resources mentioning this happening with 64bit git. Does this sound like an expected scenario? Are there any workarounds besides ensuring that all git processes on the system are compatible versions of Git+msys2?
Setup
defaults?
to the issue you're seeing?
I can ask this in the linked ticket.
Details
Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other
GfW: unknown
MinGit: VS spawns git.exe process directly via Kernel32.CreateProcess
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.