git svn – error under cygwin
$ git svn dcommit 4 [main] perl 5536 C:\cygwin\bin\perl.exe: *** fatal error - unable to remap \\?\C:\cygwin\lib\perl5\5.10\i686-cygwin\auto\List\Util\Util.dll to same address as parent: 0xA20000 != 0xB40000 Stack trace: Frame Function Args 0088B508 6102749B (0088B508, 00000000, 00000000, 00000000) 0088B7F8 6102749B (61177B80, 00008000, 00000000, 61179977) 0088C828 61004AFB (611A136C, 6125AB3C, 00A20000, 00B40000) End of stack trace
How can I fix it ? Thanks.
My system is windows 7 64 bit.
reabase helped. but I had to reboot after executing rebase.
4 Solutions collect form web for “git svn – error under cygwin”
Did you try a
rebaseall like described here?
When you are working with Cygwin, sometimes you would get an error like this
unable to remap some.dll to same address as parent someapp 4292 fork: child 3964 - died waiting for dll loading, errno 11"
Then you would need to run rebaseall.
In order to run it, close all you Cygwin windows, Execute
<cygwin_home>\bin\ash.exe, it would open a new console window
Once it has completed, you can go back to running Cygwin again without any issues 🙂
The OP gor report he had to reboot to make the
Dan Moulding mentions in the comments:
I’ll just add that closing all Cygwin windows may not be sufficient.
You should make sure all Cygwin processes and services are terminated and/or stopped (
ashshould show nothing but
ps) before rebasing.
rsenna reports in the comments:
For an explanation of why this is needed, see
fatal error - unable to remap to same address as parent: Cygwin, Ruby on Rails, System calls
So what actually is happening?
Well, in this case, the problem was a result of the way windows manages their
ASLR(address space layout randomization) to manage its
.dll‘s. It loads your dll’s into different areas of memory every time you boot your computer.
If this gets out of whack then the next time you look for that
.dll– you can crash your system. Or if you look in the wrong place, you can crash your system.
So how can this system get out of whack? Well, running your cygwin setup program can affect record keeping, especially if the
ASLRhas changed but Cygwin is holding on to an older copy (this can happen when setup doesn’t complete).
ASLR is great against malware or hacker defense. Hackers can’t constantly try new addresses for your
.dll‘s without crashing your system.
I was having this issue but running rebaseall wouldn’t fix the problem. I was attempting to run git svn dcommit and seeing the remap errors mentioned no matter how many times I ran rebaseall and/or rebooted.
Here’s a sample of what I saw. Note the reference to address 0x6FA00000
$ git svn dcommit Committing to
844 [main] perl 1136 C:\cygwin\bin\perl.exe: * fatal
error – unable to remap
C:\cygwin\bin\cygdb-4.5.dll to same
address as parent: 0x58B40000 !=
**0x6FA00000 Stack trace: Frame
Function Args 0082B458 6102792B
(0082B458, 00000000, 00000000,
00000000) 0082B748 6102792B
(6117DC60, 00008000, 00000000,
6117F977) 0082C778 61004F3B
(611A6FAC, 61247BCC, 58B40000,
6FA00000) End of stack trace
3 [main] perl 4680 fork: child 1136 – died waiting for dll loading,
I don’t think it’s important but I’m running on Windows7 Enterprise 32 bit using my company’s corporate image.
I was able to fix this following the advice I found on the Chromium wiki:
I used ListDlls.exe (http://technet.microsoft.com/en-us/sysinternals/bb896656.aspx) from cygwin to capture output of DLLs loaded in running processes and grep’ed for the address causing issues:
$ ./ListDlls.exe | tee foo
$ cat foo | grep 6fa000
0x6fa00000 0x3c000 9.05.0005.9574 C:\PROGRA~1\Sophos\SOPHOS~1\SOPHOS~1.DLL
This matched load address of a DLL provided by Sophos Security which my IT group has running on our machines by default and was the cause of the failure. rebaseall didn’t have a chance to fix the problem because the Sophos provided DLL isn’t part of cygwin.
The Chromium wiki said to choose a base address less than the DLL causing the issue so I picked 0x60000000. You may have to pick a different base address depending on the offending DLL you might see.
I reran rebaseall from a cmd.exe prompt and no other cygwin processes running.
After restarting my cygwin shell git svn dcommit worked.
Faced similar problems and it didnt go awway till i ran
run them all to fix the problem
The above answers didn’t result in a reliable fix to the problem of running cygwin git on 64bit Windows (Windows 7) for our team. I posted a question on the git mailing this and got this response from Pascal Obry:
This is a known issue. I have since a long time left Windows world but
I still have some notes to “fix” this:
From the ash shell (be sure that no Cygwin process are still running):
Try your command again. If it still doesn’t work, try instead: $
rebaseall -b 0x50000000 -o 0x80000 or -b 0xNNNN0000 where NNNN is any
hex number between 2000 and 7000. The -o option tell to leave more
space between the dlls, it may also help. It did in my case.
If you are curious, look at /usr/share/doc/Cygwin/rebase-3.0.README
for more explanation.
Pascal also noted in a followup that:
… the most important part is running peflagsall, this was the way to
fix that properly on Win7 IIRC.
Initial, but not definitive, results suggest this solution is working better than the other suggestions documented here. I will update this post in a week or so to indicate whether this recipe is sufficient to gain a permanent and reliable solution.