Git GUI 每次打开存储库时都会崩溃答案

【问题标题】：Git GUI crashes every time it opens a repositoryGit GUI 每次打开存储库时都会崩溃
【发布时间】：2012-07-10 18:36:21
【问题描述】：

从几天前开始，每次我在仓库中启动 Git GUI 时，它都会显示这个可怕的错误信息，并在我单击确定后退出：

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.

它只发生在 Git GUI 中，并且只在存储库（旧的或新创建的）中发生。 Git Bash 中的常用命令（包括提交）工作正常。

卸载并使用较新的软件包重新安装（只有较小的版本更改）并没有解决问题。旧存储库和新创建的存储库仍然会发生这种情况。

在干净的机器上这个问题不会重现，所以我猜这是我的盒子上的东西，但我不记得安装了任何有趣的东西。我确实记得在很长一段时间后关闭了我的盒子，所以也许一些 Windows 更新可能触发了这个 - 这也可以解释为什么另一台机器不会受到影响 - 距离上次 Win 更新已经 2-3 个月了。

任何想法如何阐明这一点？（因为我只能在单机上看到它，所以在我知道这不是我/其他应用程序的错之前，我不想将其提交给官方跟踪器......）

更新在第一次 cmets 之后：

如果你删除或重命名钩子脚本，它会起作用吗？

够好笑，但是钩子脚本实际上根本不存在（没有钩子脚本存在——.git\hooks 中只有 *.sample 文件）。甚至在其他地方也没有（git程序目录等）
跟踪它，以便您知道它运行了哪些命令 - 从 git-bash 运行 git gui --trace

遗憾的是，这不会向 shell 输出任何内容。行为是一样的。
也许可以把 gdb 放进去。

我试过了，但 gdb 没有输出任何有用的东西。但是，我没有任何经验使用 GDB，我可能做错了。我有一个MinGW's gdb，从命令运行它以 git.exe 作为参数提示，然后运行 run gui。 gdb 没有输出任何东西有趣：
```
(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)  
```
但我几乎可以肯定我做错了，所以建议非常受欢迎:)
确保您没有安装 cygwin 或至少它不存在于您的路径

我确实安装了 cygwin（就像我一直安装的那样，在 git 崩溃之前）。从 Cygwin 我只在路径中有一些 *.bat 启动器和一些 *.dll 文件，但我已经检查过 ProcMon 它不会触及它们，即使我将它们从路径中删除，我仍然会得到同样的崩溃。

【问题讨论】：

如果您删除或重命名挂钩脚本，它是否有效？ .git/hooks/prepare-commit-msg
跟踪它，以便您知道它运行了哪些命令 - 从 git-bash 运行 git gui --trace。当它运行 prepare-commit-hook 时，它将发出它运行的命令，您可以查看该命令以获取更多调试信息。也许在那里得到gdb。它抱怨 cygwin 堆的事实是可疑的。确保您没有安装 cygwin，或者至少它根本不存在于您的 PATH 中。 cygwin 和 msys 不能混用。
@patthoyts, fork0 感谢指点，更新了 Q 的回复
我现在看到了与 msysgit.googlecode.com/files/Git-1.8.3-preview20130601.exe 类似的问题 -- github.com/msysgit/msysgit/issues/123 。但我没有更多有用的信息。
@imz--IvanZakharyaschev 我不敢相信我忘记在 Q 中添加版本并且侥幸逃脱。 ;) 不幸的是，我不能回来查看，我已经在另一家公司工作了。我猜测它是当时在 googlecode 页面上稳定可用的东西（不确定是否为 1.8*）

标签： git dll msysgit

【解决方案1】：

这对我有用。

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

解决方案：

更改msysgit.dll的基地址

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

【讨论】：

我不知道 rebase 与 dll 有什么关系（如果需要 rebase，感觉 dll 本身处于源代码控制之下）但我不在乎。它有效:)
适用于 Windows 10 上损坏的 GitHub 桌面客户端
@PawelCioch 这是一种不同类型的变基，与 git 无关，它会更改加载 DLL 的内存中的基地址。

【解决方案2】：

我也遇到过这个问题

我已经解决了

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

显然这是由某些功能引起的，替换 dll 可以解决大多数人的问题

万一网站宕机 -

虚拟 Alloc 指针为空

在极少数情况下，运行 make 可能会导致类似以下的错误：

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

这是一个影响极少数客户的问题，并且取决于他们同时运行的其他应用程序。

这是由我们用来为产品提供构建环境的 MSYS 二进制文件中的一项功能引起的。

如果发生这种情况，您可以替换文件 \msys\bin\msys-1.0.dll 使用随附的 zipfile 中的文件。 msys-1.0.zip

请注意，这并不能解决问题，而是移动 DLL 基地址。不幸的是，这个替换 DLL 也可能发生错误，这再次取决于正在运行的其他应用程序。

【讨论】：

可能是实际问题的线索，关闭并重新打开 cli 使这个问题对我来说消失了。它只有在长时间正常工作后才会发生。就我而言，我有两个遥控器，前面有不同数量的提交。如果再次发生，将替换 dll。谢谢
不适用于损坏的 GitHub 桌面客户端：gyazo.com/a402712617d4295f3385d5c083745a5e

【解决方案3】：

在另一个 Windows 更新和操作系统重新启动后，问题消失了。

似乎其中一个更新引入了一个已在另一个更新中修复的错误。或者它可以成为“月相”错误。

我想我们永远不会知道...

【讨论】：

【解决方案4】：

我也遇到了这个问题，这是因为 MacType 干扰了 bash.exe 和 msys1.0.dll。（MacType 是一个用于 Windows 的字体平滑程序，它试图模拟 OS-X 样式的字体光栅化。）仅在我需要的程序上启用 MacType，而不是在试图加载 bash.exe 的 Console2 窗口上解决了这个问题。

也许这会帮助其他人修复错误。

【讨论】：

【解决方案5】：

我遇到了同样的问题。对我有用的解决方案与 XandrGuard 建议的解决方案几乎相同

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

解决方案在这里解释http://jakob.engbloms.se/archives/1403

对我来说，解决方案略有不同。原来是

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

希望它能帮助那些试图用谷歌搜索问题的人

【讨论】：

这个解决方案最适合我，因为它直接指向 Git GUI 应用程序
成功了，虽然第一次尝试失败了：ReBaseImage (msys-1.0.dll) failed with last error = 2 以管理员身份从命令提示符重新运行它。

【解决方案6】：

在 Win64 机器上安装 1.8.0 后，我遇到了同样的问题。我通过删除 1.8.0 并安装 1.7.11 解决了这个问题

【讨论】：

很遗憾，OP 没有指定版本，因此我们无法将他的报告与您的情况进行比较。

【解决方案7】：

只需在您的 C:\ 驱动器上搜索所有 msys-1.0.dll，然后将 Git 使用的那个放在第一位。

就我而言，我只是更改了以下顺序：

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

通过使 Git 路径 C:\prgs\git\PortableGit-1.8.5.2-preview20131230\bin\ 在我的 %PATH% 中排在第一位，错误消息消失了！

无需重新启动，甚至无需更改 DOS 会话。
在该 DOS 会话中更新 %PATH% 后，git 命令就可以工作了。

旁注，关于 gdb：

使用 Git 2.25.2（2020 年 3 月）增加了更好的 gdb 调试体验。

参见Johannes Schindelin (dscho) 的commit 08809c0（2020 年 2 月 13 日）。
^{（由 Junio C Hamano -- gitster -- 合并于 commit e154451，2020 年 2 月 17 日）}

mingw: 添加辅助函数，将 GDB 附加到当前进程

^{签字人：约翰内斯·辛德林}

在调试 Git 时，交叉生成的进程可能会让事情变得相当困难，尤其是当一个 Unix shell 脚本被混入调用 git.exe 之后会出现段错误时。

为了帮助调试这些事情，我们引入了open_in_gdb() 函数，该函数可以在发生段错误的代码位置（或尽可能接近）调用；这将打开一个新的 MinTTY 窗口，其中包含已附加到当前进程的 GDB。

灵感来自 Derrick Stolee。

然后new function open_in_gdb()有评论：

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

【讨论】：

mingw: 添加辅助函数，将 GDB 附加到当前进程

`mingw`: 添加辅助函数，将 GDB 附加到当前进程