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 failed:

      0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
AllocationBase 0x0, BaseAddress 0x68560000, RegionSize 0x260000, State 0x10000
C:\Program Files (x86)\Git\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0

You must correct the above errors before committing.

It only happens with Git GUI and only when in repository (old or newly created one). Common commands in Git Bash including commit work fine.

Un-installing and re-installing with newer package (only minor version change) did not remove the issue. It still happens with old repositories as well as with newly created ones.

On a clean machine this issue does not reproduce, so I guess it's something on my box, but I don't remember installing anything funny. I do remember turning off my box after a long time though, so maybe some Windows Update could have triggered this--that would also explain why the other machine does not suffer--it's 2-3 months since last Win update there.

Any ideas how to shed light into this? (As I can only see it on single machine, I don't feel like submitting it to official tracker before I know it's not my/other app's fault...)

---

Update after first comments:

• If you remove or rename the hook script, does it work?

  Funny enough, but the hook script actually does not exist at all (no hook scripts are present--there are only *.sample files in .git\hooks). Not even elsewhere (git program dir, etc.)

• Trace it so you know what commands it ran - from git-bash run git gui --trace

  Sadly this does not output anything to the shell. Behaviour is the same.

• Maybe get gdb in there.

  I tried but gdb did not output anything useful. However, I don't have any experience with GDB, I'm probably doing it wrong. I got a MinGW's gdb, ran it from command prompt with git.exe as argument and then ran run gui. gdb did not output anything interesting:

  (gdb) run gui
  Starting program: C:\Program Files (x86)\Git\bin\git.exe gu
  [New Thread 8264.0x1ce4]
  [New Thread 8264.0x394]
  [Inferior 1 (process 8264) exited with code 01]
  (gdb)  
  

  But I'm almost sure I'm Doing It Wrong, so advice is more than welcome :)

• Make sure you don't have cygwin installed or at least that it is not present in your PATH at all

  I do have cygwin installed (as I always had, before git broke). From Cygwin I only have in path some *.bat launchers and some *.dll files, but I have checked with ProcMon that it does not touch them and even if I remove them from the path I still get the same crash.

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

---

Answer 3

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