1

I have installed git and cygwin for my windows and it was working fine. but in recent days i am getting some fatal error.

      0 [main] cut (26740) C:\Users\bin\cut.exe: *** fatal error - cygheap base mismatch detected - 0x180347408/0x180346408.
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.

i tried to remove the cygwin1.dll and tried but still i am getting the same error. how can we fix this. any solution would be helpful.

Sayon
  • 85
  • 8
  • have you tried to use Cygwin git package instead, instead of mixing git for windows with Cygwin ? – matzeri Mar 08 '23 at 09:19
  • It is possible to have both cygwin and git4windows installed both at the same problem, I have done for several years (but I have not set up neither to "leak" its bin directories into PATH in cmd/powershell). Having a `cut.exe` binary in your home `bin` directory seems very suspect, is it maybe an old copy that now refers to a old dll version that has been updated away? You should only run binaries directly from the `bin` directory where cygwin/git4windows is installed. – hlovdal Mar 08 '23 at 17:51
  • Does this answer your question? [Cygwin/Git error cygheap base mismatch detected](https://stackoverflow.com/questions/8107319/cygwin-git-error-cygheap-base-mismatch-detected) – tripleee Mar 10 '23 at 06:01
  • Perhaps a better duplicate is https://stackoverflow.com/questions/771756/what-is-the-difference-between-cygwin-and-mingw though it approaches the question from the opposite direction. – tripleee Mar 10 '23 at 06:03
  • check if, as [documented in my answer](https://stackoverflow.com/a/75730913/6309), [Git 2.40.0](https://github.com/git-for-windows/git/releases/tag/v2.40.0.windows.1) would help. – VonC Mar 14 '23 at 08:58
  • In your Cygwin installation, did you put the Cygwin base directory into C:\Users? This would be a highly unlikely location. I suggest that you tell us a bit about your installation - where did you put the Cygwin installation, and where did you put Git for Windows? Also explain why you want to have both. Though it is technically possible, using both in parallel just begs for trouble. – user1934428 Mar 14 '23 at 10:35

2 Answers2

0

The error message is misleading

Git for Windows do NOT use cygwin1.dll .It uses a modified version called msys-2.0.dll coming from the Mingw64 project

$ objdump -x cut.exe |grep "DLL Name:"
        DLL Name: msys-intl-8.dll
        DLL Name: msys-2.0.dll
        DLL Name: KERNEL32.dll

but they forget to amend the error messages

$ grep cygwin1.dll msys-2.0.dll
grep: msys-2.0.dll: binary file matches

The probably cause is that you have two programs using Mingw64 infrastructure in your PATH. I suggest you to sanitize the PATH in such way that git for Windows is not colliding with them.

matzeri
  • 8,062
  • 2
  • 15
  • 16
  • Git 2.40 should help. [See my answer for the details](https://stackoverflow.com/a/75730913/6309) – VonC Mar 14 '23 at 08:57
  • Maybe, but avoiding to have clogged up PATH with a lot of software directories, will surely work. I always test multiple installations of Cygwin and they never collide as none of the directory are in Windows PATH. When running one instance the PATH is very minimal and restricted to that Cywin installation and to the Windows10 main directories – matzeri Mar 14 '23 at 21:37
0

Try and upgrade to Git for Windows 2.40.0 (or the latest)

It includes:

When trying to call Cygwin (or for that matter, MSYS2) programs from Git Bash, users would frequently be greeted with cryptic error messages about a "cygheap" or even just an even more puzzling exit code 127.

Many of these calls now succeed, allowing basic interactions.

While it is still not possible for, say, Cygwin's vim.exe to interact with the Git Bash's terminal window, it is now possible for Cygwin's zstd.exe in conjunction with Git for Windows' tar.exe to handle .tar.zst archives.

See git-for-windows/git issue 4255 for a analysis of the issue:

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.

Johannes Schindelin adds:

The root cause of these issues is that the MSYS2 runtime (or for that matter, the Cygwin runtime, from which the MSYS2 runtime is forked) needs to emulate certain POSIX functionality, e.g. the fork() syscall, and said emulation requires the child processes to talk to their parent processes "before the child process starts up for real".
This communication happens via shared memory that is called the "Cygwin heap".

And naturally, such communication will only succeed if both parent and child process have a very, very similar idea of the shape of that Cygwin heap.
If they have even slightly different ideas, some of those bytes in that shared memory are misinterpreted by one side and chaos ensues. Or crashes. Or aborts with a cryptic message about some "cygheap base mismatch, whatever that is".

Now, the Cygwin runtime is very careful to version the definition of that Cygwin heap so that even different Cygwin runtimes have a chance to talk to each other.
It is quite possible that by rebasing the MSYS2 runtime's custom changes on top of newer Cygwin runtime versions, we miss some steps and inadvertently break that shared memory format versioning.

I implemented a pretty big hammer here, which seems to do the job by telling any two different MSYS2 runtime versions that they simply cannot talk to each other.

See

VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250