Git GUI crashes every time it opens a repository

Question

Since few days ago, every time I start Git GUI in a repository, it displays this horrifying error message and quits after I click OK:

prepare-commit-msg hook fai         


        

Answer 1

This worked for me.

http://www.trinitycore.org/f/topic/5194-msysgit-couldnt-reserve-space-for-cygwins-heap/

Solution:

Change the base address of the msysgit.dll

c:\msysgit\bin>rebase.exe -b 0x50000000 msys-1.0.dll

Answer 2

I had the same problem. The solution which worked for me was almost same as the one suggested by XandrGuard

c:\msysgit\bin>rebase.exe -b 0x50000000 msys-1.0.dll

Solution is explained here http://jakob.engbloms.se/archives/1403

For me solution was slightly different. It was

C:\Program Files (x86)\Git\bin>rebase.exe -b 0x50000000 msys-1.0.dll

Hope it helps people who are trying to google the problem

Answer 3

Simply make a search for all msys-1.0.dll on your C:\ drive, and make the one used by Git comes first.

In my case, I simply changed the order of:

C:\prgs\Gow\Gow-0.7.0\bin\msys-1.0.dll
C:\prgs\git\PortableGit-1.8.5.2-preview20131230\bin\msys-1.0.dll

By making the Git path C:\prgs\git\PortableGit-1.8.5.2-preview20131230\bin\ come first in my %PATH%, the error message disappeared!

No need to reboot or to even change the DOS session.
Once the %PATH% is updated in that DOS session, the git commands just work.

---

Sidenote, regarding gdb:

With Git 2.25.2 (March 2020) adds a better gdb debugging experience.

See commit 08809c0 (13 Feb 2020) by Johannes Schindelin (dscho).
^{(Merged by Junio C Hamano -- gitster -- in commit e154451, 17 Feb 2020)}

mingw: add a helper function to attach GDB to the current process

^{Signed-off-by: Johannes Schindelin}

When debugging Git, the criss-cross spawning of processes can make things quite a bit difficult, especially when a Unix shell script is thrown in the mix that calls a git.exe that then segfaults.

To help debugging such things, we introduce the open_in_gdb() function which can be called at a code location where the segfault happens (or as close as one can get); This will open a new MinTTY window with a GDB that already attached to the current process.

Inspired by Derrick Stolee.

Then new function open_in_gdb() has the comment:

/*
 * For debugging: if a problem occurs, say, in a Git process that is spawned
 * from another Git process which in turn is spawned from yet another Git
 * process, it can be quite daunting to figure out what is going on.
 *
 * Call this function to open a new MinTTY (this assumes you are in Git for
 * Windows' SDK) with a GDB that attaches to the current process right away.
 */

Answer 4

After another Windows Update and OS restart, the problem disappeared.

It seems like one of update introduced a bug which was fixed in another one. Or it could be a "phase-of-the-moon" bug.

I guess we'll never know...

Answer 5

I ran into this too, and it was because MacType was interfering with bash.exe and msys1.0.dll. (MacType is a font smoothing program for Windows that tries to emulate OS-X style font rasterization.) Enabling MacType only on the programs I need it, and not on the Console2 window that was trying to load bash.exe fixed the problem.

Maybe that will help someone else fix the error.

Answer 6

I've had this problem as well

I've solved it with

http://support.code-red-tech.com/CodeRedWiki/VirtualAllocPointerNull

Apparently this is caused by some feature, and replacing the dll fixes it for most people

in case the website is down -

---

Virtual Alloc pointer is null

Very rarely, running make may result in an error similar to this:

0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
AllocationBase 0x0, BaseAddress 0x71110000, RegionSize 0x350000, State 0x10000
\msys\bin\make.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0

This is a problem that affects a tiny minority of customers, and depends on what other applications they are running at the same time.

This is caused by a feature in the MSYS binaries that we use to provide the the build environment for the product.

If this happens, you can replace the file \msys\bin\msys-1.0.dll with the file in the attached zipfile. msys-1.0.zip

Note that this does not fix the problem, rather it moves DLL base address. Unfortunately, it is possible the error may occur with this replacement DLL too, again depending on what other applications are running.

---