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.

If you remove or rename the hook script, does it work? `.git/hooks/prepare-commit-msg` — fork0, Jul 10 '12 at 18:41
Trace it so you know what commands it ran - from git-bash run `git gui --trace`. When it runs the prepare-commit-hook it will emit the command that it runs and you can look at that command for further debug info. Maybe get gdb in there. The fact that it complains about cygwin's heap is suspicious. Make sure you don't have cygwin installed or at least that it is not present in your PATH at all. cygwin and msys do not mix. — patthoyts, Jul 10 '12 at 21:37
@patthoyts, fork0 Thanks for pointers, updated Q with replies — Alois Mahdal, Jul 11 '12 at 09:41
I see a similar issue with https://msysgit.googlecode.com/files/Git-1.8.3-preview20130601.exe now -- https://github.com/msysgit/msysgit/issues/123 . But I have no more helpful information about this. — imz -- Ivan Zakharyaschev, Jun 20 '13 at 11:04
BTW, which version of Git for Windows were you using when this error happened? — imz -- Ivan Zakharyaschev, Jun 20 '13 at 11:09
@imz--IvanZakharyaschev I can't believe I forgot to add version to the Q and got away with that. ;) Unfortunately I can't check back, I'm already working at a different company. I'd wildly guess it was something that was available as stable at the time at the googlecode page (not sure if 1.8*) — Alois Mahdal, Jun 20 '13 at 11:24

score 10 · Answer 1 · answered Apr 07 '14 at 10:45

10

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

answered Apr 07 '14 at 10:45

XandrGuard

141
1
3

I have no idea what rebase has to do with dll (feels like dll itself is under source control if needs rebasing) but I don't care. It works :) – Pawel Cioch Jul 29 '15 at 20:55
Works for broken GitHub Desktop client on Windows 10 – Amadeusz Wieczorek Nov 03 '15 at 17:22
1

@PawelCioch this is a different kind of rebase, unrelated to git, which changes the base address in memory that a DLL is loaded at. – Sam Feb 28 '16 at 23:16

Nick Ginanto · Answer 2 · 2013-06-20T20:19:25.270

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.

maybe a clue to the actual problem, closing and reopening the cli made this problem go away for me. It only occurred after working correctly for a long time. In my case I had two remotes with different number of commits ahead. Will replace the dll if it happens again. Thanks — isimmons, Dec 31 '13 at 19:56
Did not work for a broken GitHub desktop client: https://gyazo.com/a402712617d4295f3385d5c083745a5e — Amadeusz Wieczorek, Nov 03 '15 at 17:17

score 3 · Accepted Answer · answered Jul 12 '12 at 08:41

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

answered Jul 12 '12 at 08:41

Alois Mahdal

10,763
7
51
69

score 3 · Answer 4 · answered Nov 04 '13 at 16:48

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.

score 3 · Answer 5 · answered Jun 25 '14 at 10:28

3

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

answered Jun 25 '14 at 10:28

zainengineer

13,289
6
38
28

This solution worked best for me, since it directly points to the Git GUI application – JPeroutek May 31 '16 at 12:00
That worked, though the first attempt failed: `ReBaseImage (msys-1.0.dll) failed with last error = 2` Re-running it from a command prompt as administrator did the trick. – df778899 Jun 11 '16 at 16:17

score 2 · Answer 6 · answered Jan 21 '13 at 12:38

2

I was getting this same issue after installing 1.8.0 on a Win64 machine. I solved the issue by removing 1.8.0 and installing 1.7.11

answered Jan 21 '13 at 12:38

sigma9

21
2

Unfortunately, the OP didn't specifiy the version, so we can't compare his report to your case. – imz -- Ivan Zakharyaschev Jun 20 '13 at 11:10

score 1 · Answer 7 · edited Jun 20 '20 at 09:12

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

Git GUI crashes every time it opens a repository

7 Answers7

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

Linked

Git GUI crashes every time it opens a repository

7 Answers7

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

Linked

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