Git 扩展:Win32 错误 487:无法为 cygwin 的堆保留空间,Win32 错误 0

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/18502999/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-09-10 16:51:02  来源:igfitidea点击:

Git Extensions: Win32 error 487: Couldn't reserve space for cygwin's heap, Win32 error 0

gitcygwingit-extensions

提问by Uchia Itachi

Git Extensions:Everything was working fine until yesterday.

Git 扩展:直到昨天一切正常。

But suddenly I am get this error when I try to pull some repositories using git extensions

但是当我尝试使用一些存储库时突然出现此错误 git extensions

C:\Program Files\Git\bin\git.exe pull --progress "origin" 
Done
    0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487
AllocationBase 0x0, BaseAddress 0x68560000, RegionSize 0x390000, State 0x10000
C:\Program Files\Git\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0

It is happening for all the repositories which I have cloned. But, my git bashis working fine. I don't have any idea what is going on. Any idea as to why this is happening?

我克隆的所有存储库都在发生这种情况。但是,我的git bash工作正常。我不知道发生了什么。知道为什么会这样吗?

采纳答案by Greg Hewgill

Cygwin uses persistent shared memory sections, which can on occasion become corrupted. The symptom of this is that some Cygwin programs begin to fail, but other applications are unaffected. Since these shared memory sections are persistent, often a system rebootis needed to clear them out before the problem can be resolved.

Cygwin 使用持久共享内存部分,这些部分有时会损坏。其症状是某些 Cygwin 程序开始失败,但其他应用程序不受影响。由于这些共享内存部分是永久性的,因此在解决问题之前,通常需要重新启动系统来清除它们。

回答by zainengineer

I had the same problem. I found solution here http://jakob.engbloms.se/archives/1403

我有同样的问题。我在这里找到了解决方案http://jakob.engbloms.se/archives/1403

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

For me solution was slightly different. It was

对我来说,解决方案略有不同。它是

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

Before you rebase dlls, you should make sure it is not in use:

在重新设置 dll 之前,您应该确保它没有被使用:

tasklist /m msys-1.0.dll

And make a backup:

进行备份:

copy msys-1.0.dll msys-1.0.dll.bak

If the rebase command fails with something like:

如果 rebase 命令失败,如下所示:

ReBaseImage (msys-1.0.dll) failed with last error = 6

ReBaseImage (msys-1.0.dll) 失败,最后一个错误 = 6

You will need to perform the following steps in order:

您需要按顺序执行以下步骤:

  1. Copy the dll to another directory
  2. Rebase the copy using the commands above
  3. Replace the original dll with the copy.
  1. 将dll复制到另一个目录
  2. 使用上面的命令重新设置副本
  3. 用副本替换原始dll。

If any issue run the commands as Administrator

如果有任何问题,请以管理员身份运行命令

回答by Yirkha

tl;dr: Install 64-bit Git for Windows 2.

tl;dr:为 Windows 2安装64 位 Git



Technical details

技术细节

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

This symptom by itself has nothing to do with image bases of executables, corrupted Cygwin's shared memory sections, conflicting versions of DLLs etc.

此症状本身与可执行文件的映像库、损坏的 Cygwin 共享内存部分、冲突的 DLL 版本等无关。

It's Cygwin code failing to allocate a ~5 MB large chunk of memory for its heap at this fixed address 0x68570000, while only a hole ~2.5 MB large was apparently available there. The relevant code can be seen in msysgit source.

Cygwin 代码未能为其在这个固定地址 0x68570000 的堆分配大约 5 MB 的大内存块,而那里显然只有大约 2.5 MB 的空洞可用。相关代码可以在msysgit source 中看到。



Why is that part of address space not free?

为什么那部分地址空间不是免费的?

There can be many reasons. In my case it was some other modules loaded at a conflicting address:

可能有很多原因。就我而言,它是在冲突地址加载的其他一些模块:

Process modules in Process explorer

流程浏览器中的流程模块

The last address would be around 0x68570000 + 5 MB = 0x68C50000, but there are these WOW64-related DLLs loaded from 0x68810000 upwards, which block the allocation.

最后一个地址大约是 0x68570000 + 5 MB = 0x68C50000,但是从 0x68810000 向上加载了这些与 WOW64 相关的 DLL,这会阻止分配。

Whenever there is some shared DLL, Windows in general tries to load it at the same virtual address in all processes to save some relocation processing. It's just a matter of bad luck that these system components got somehow loaded at a conflicting address this time.

每当有一些共享 DLL 时,Windows 通常会尝试在所有进程中将其加载到相同的虚拟地址,以节省一些重定位处理。这只是一个运气不好的事,这些系统组件得到了某种程度上加载在冲突地址这段时间



Why is there Cygwin in your Git?

为什么你的 Git 中有 Cygwin?

Because Git is a rich suite consisting of some low level commands and a lot of helpful utilities, and mostly developed on Unix-like systems. In order to be able to build it and run it without massive rewriting, it need at least a partial Unix-like environment.

因为 Git 是一个丰富的套件,由一些低级命令和许多有用的实用程序组成,并且主要是在类 Unix 系统上开发的。为了能够在不大量重写的情况下构建和运行它,它至少需要一个部分类 Unix 环境。

To accomplish that, people have invented MinGW and MSYS - a minimal set of build tools to develop programs on Windows in an Unix-like fashion. MSYS also contains a shared library, this msys-1.0.dll, which helps with some of the compatibility issues between the two platforms during runtime. And many parts of that have been taken from Cygwin, because someone already had to solve the same problems there.

为了实现这一点,人们发明了 MinGW 和 MSYS——一组最小的构建工具,以类似 Unix 的方式在 Windows 上开发程序。MSYS 还包含一个共享库 this msys-1.0.dll,它有助于解决运行时两个平台之间的一些兼容性问题。其中很多部分都来自 Cygwin,因为已经有人在那里解决了同样的问题。

So it's not Cygwin, it's MinGW's runtime DLL what's behaving weird here.

所以这不是 Cygwin,而是 MinGW 的运行时 DLL 在这里表现得很奇怪。

In Cygwin, this code has actually changed a lot since what's in MSYS 1.0 - the last commit message for that filesays "Import Cygwin 1.3.4", which is from 2001!

在 Cygwin 中,自从 MSYS 1.0 中的内容以来,此代码实际上发生了很大变化 - 该文件的最后一条提交消息显示“导入 Cygwin 1.3.4”,这是 2001 年的!

Both current Cygwinand the new version of MSYS- MSYS2 - already have different logic in place, which is hopefully more robust. It's only old versions of Git for Windows which have been still built using the old broken MSYS system.

无论当前的CygwinMSYS的新版本- MSYS2 -已经到位不同的逻辑,这是希望更稳健。它只是用于 Windows 的旧版本 Git,它们仍然使用旧的损坏的 MSYS 系统构建。



Clean solutions:

清洁解决方案:

  • Install Git for Windows 2- it is built with the new, properly maintained MSYS2and also has many new features, plenty of bug fixes, security improvements and so on. If at all possible, it is also recommended to use the 64-bit version. But the rebase workaroundis performed automatically behind the scenes for 32-bit systems, so the chances of the problem happening there should be lower too.
  • Simply restarting the computer to clean the address space (loading these modules at a different random address) might work, but really, just upgrade to Git for Windows 2 to get the security fixes if nothing else.
  • 安装适用于 Windows 2 的 Git- 它是用新的、维护良好的 MSYS2 构建的,还有许多新功能、大量错误修复、安全改进等。如果可能,也建议使用 64 位版本。但是对于 32 位系统,rebase 解决方法是在幕后自动执行的,因此在那里发生问题的可能性也应该较低。
  • 简单地重新启动计算机以清理地址空间(在不同的随机地址加载这些模块)可能会起作用,但实际上,只需升级到适用于 Windows 2 的 Git 即可获得安全修复程序。

Hacky solutions:

哈奇解决方案:

  • Changing PATHcan sometimes work because there might be different versions of msys-1.0.dllin different versions of Git or other MSYS-based applications, which perhaps use different address, different size of this heap etc.
  • Rebasing msys-1.0.dllmight be a waste of time, because 1) being a DLL, it already has relocation information and 2) "in any version of Windows OS there is no guarantee that a (...) DLL will always load at same address space" anyway (source). The only way this can help is if the msys-1.0.dllitself loads at the conflicting address it's then trying to use. Apparently that's the case sometimes, as this is what the Git for Windows guys are doing automatically on 32-bit systems.
  • Considering the findings above, I originally binary patched the msys-1.0.dllbinary to use a different value for _cygheap_startand that resolved the problem immediately.
  • 更改PATH有时会起作用,因为msys-1.0.dll在不同版本的 Git 或其他基于 MSYS 的应用程序中可能有不同的版本,这些应用程序可能使用不同的地址、不同大小的堆等。
  • 重新定位msys-1.0.dll可能是浪费时间,因为 1) 作为一个 DLL,它已经有重定位信息和 2)“在任何版本的 Windows 操作系统中,都不能保证 (...) DLL 将始终加载到相同的地址空间”无论如何(来源)。这可以提供帮助的唯一方法是如果它msys-1.0.dll本身加载到它然后尝试使用的冲突地址。显然有时就是这种情况,因为这就是 Git for Windows 人员在32 位系统上自动执行的操作
  • 考虑到上述发现,我最初对二进制文件进行了二进制修补msys-1.0.dll以使用不同的值,_cygheap_start并立即解决了问题。

回答by Tisch

Very simple verison of the rebase solution:

变基解决方案的非常简单的版本:

Go to the folder where git is installed, such as:

进入安装git的文件夹,如:

C:\Program Files (x86)\Git\bin

By holding shift and right clicking in the folder, you should be able to open a command prompt as administrator from there (thanks to https://stackoverflow.com/users/355389/darren-lewisfor that comment),

通过按住 shift 并右键单击文件夹,您应该能够从那里以管理员身份打开命令提示符(感谢https://stackoverflow.com/users/35538​​9/darren-lewis的评论),

Then run:

然后运行:

rebase.exe -b 0x50000000 msys-1.0.dll

This fixed it for me when the restart approach didn't work.

当重新启动方法不起作用时,这为我修复了它。

Hope it helps.

希望能帮助到你。

回答by VonC

I have seen the same error message after upgrading to git1.8.5.2:

升级到 git1.8.5.2 后,我看到了相同的错误消息:

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

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

For instance, 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.

通过将 Git 路径C:\prgs\git\PortableGit-1.8.5.2-preview20131230\bin\放在 my 中%PATH%,错误消息消失了。

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.

无需重新启动或什至更改 DOS 会话。
一旦%PATH%在那个 DOS 会话中更新,git 命令就可以工作了。



Note that carmbresterand Sixto Saezboth report below (in the comments) having to rebootin order to fix the issue.
Note: First, also removing any msys-1.0.dll, like one in %LOCALAPPDATA%

请注意,carmbresterSixto Saez都在下面(在评论中)报告了必须重新启动才能解决问题。
注意:首先,还要删除 any msys-1.0.dll,例如%LOCALAPPDATA%

回答by RobertB

If a reboot does not correct the problem (as suggested by Greg Hegwill's answer) then check your PATH for conflicting installation(s) of the msys-1.0.dll (and possibly other related DLLs).

如果重新启动不能解决问题(正如 Greg Hegwill 的回答所建议的那样),请检查您的 PATH 是否存在冲突的 msys-1.0.dll 安装(以及可能的其他相关 DLL)。

In my particular situation MinGW's installation of msys has a copy of that DLL in its bindirectory (<MinGW_Install_Path>\msys\1.0\bin), and it was listed in the PATH. Git's cmddirectory was listed in the PATH, but its binwas not. (Git's version of msys-1.0.dll is in the bindirectory. Apparently the default installation of MSys-Git does not add its binto the PATH.)

在我的特殊情况下,MinGW 的 msys 安装在其bin目录 ( <MinGW_Install_Path>\msys\1.0\bin) 中有该 DLL 的副本,并且它已列在 PATH 中。Git 的cmd目录列在 PATH 中,但它bin没有。(Git 的 msys-1.0.dll 版本在该bin目录中。显然 MSys-Git 的默认安装没有将其添加bin到 PATH。)

A temporary fix was to add Git's bindirectory to the PATH so that it appears before MinGW's paths. (A more permanent fix will likely involve sorting out the path conflicts between MinGW's msys and Git's and/or removing the duplicate msys installations.)

临时修复是将 Git 的bin目录添加到 PATH 中,使其出现在 MinGW 的路径之前。(更永久的修复可能涉及解决 MinGW 的 msys 和 Git 之间的路径冲突和/或删除重复的 msys 安装。)

回答by radiohead

Just want to share my experience here. I came across the same issue while cross compiling for MTK platform on a Windows 64 bit machine. MinGW and MSYS are involved in the building process and this issue popped up. I solved it by changing the msys-1.0.dllfile. Neither rebase.exenor system reboot worked for me.

只是想在这里分享我的经验。我在 Windows 64 位机器上交叉编译 MTK 平台时遇到了同样的问题。MinGW 和 MSYS 参与了构建过程,并且出现了这个问题。我通过更改msys-1.0.dll文件解决了它。既不rebase.exe也不重新启动系统对我来说有效。

Since there is no rebase.exe installed on my computer. I installed cygwin64 and used the rebase.exeinside:

因为我的电脑上没有安装 rebase.exe。我安装了cygwin64并使用了rebase.exe里面:

C:\cygwin64\bin\rebase.exe -b 0x50000000 msys-1.0.dll

Though rebasing looked successful, the error remained. Then I ran rebasecommand inside Cygwin64 terminal and got an error:

尽管变基看起来很成功,但错误仍然存​​在。然后我rebase在 Cygwin64 终端内运行命令并得到一个错误:

$ rebase -b 0x50000000 msys-1.0.dll
rebase: Invalid Baseaddress 0x50000000, must be > 0x200000000

I later tried a couple address but neither of them worked. So I ended up changing the msys-1.0.dllfile and it solved the problem.

后来我尝试了几个地址,但都没有奏效。所以我最终更改了msys-1.0.dll文件并解决了问题。

回答by P_O

I ran into this today. Led by Greg Hewgill's answer, I looked at running processes on my system to see if anything was "stuck" or if other users were logged into the machine doing anything with git. I then launched cygwin (installed separately) on this particular machine. It launched ok. I closed it and then tried the Git Extensions again (I was trying a pull operation) and it worked. Not sure if the launching of cygwin cleared something that was shared but this is the first time I ran into this error and this seemed to fix it for me.

我今天遇到了这个。在 Greg Hewgill 的回答的带领下,我查看了我系统上正在运行的进程,看看是否有任何东西“卡住”,或者其他用户是否登录到机器上使用 git 执行任何操作。然后我在这台特定的机器上启动了 cygwin(单独安装)。它启动正常。我关闭它,然后再次尝试 Git 扩展(我正在尝试拉操作)并且它起作用了。不确定 cygwin 的启动是否清除了共享的内容,但这是我第一次遇到此错误,这似乎为我解决了问题。

回答by Koshmaar

I had the same problem, after some Windows 8.0 crash and update, on msys git 1.9. I didn't find any msys/git in my path, so I just added it in windows local-user envinroment settings. It worked without restarting.

在 Windows 8.0 崩溃和更新后,我在 msys git 1.9 上遇到了同样的问题。我在我的路径中没有找到任何 msys/git,所以我只是将它添加到 Windows 本地用户环境设置中。它无需重新启动即可工作。

Basically, similiar to RobertB, but I didn't have anygit/msys in my path.

基本上,类似于 RobertB,但我的路径中没有任何git/msys。

Btw:

顺便提一句:

  1. I tried using rebase -b blablabla msys.dll, but had error "ReBaseImage (msys-1.0.dll) failed with last error = 6"

  2. if you need this quickly and don't have time debugging, I noticed "Git Bash.vbs" in Git directory successfuly starts bash shell.

  1. 我尝试使用 rebase -b blablabla msys.dll,但出现错误“ReBaseImage (msys-1.0.dll) failed with last error = 6”

  2. 如果你很快需要这个并且没有时间调试,我注意到 Git 目录中的“Git Bash.vbs”成功启动了 bash shell。

回答by IgorGanapolsky

This error happens very rarely on my Windows machine. I ended up rebooting the machine, and the error went away.

这个错误在我的 Windows 机器上很少发生。我最终重新启动了机器,错误消失了。