_Delta.dll to same address as parent -- 0x6E750000

[CADbloke]

same as #300 which seems to have been thrown in the Too-Hard basket.

Using Git-1.9.5-preview20141217 on Win7 x64

Error messages ...

C:\Codez\Temp\zSVNtest\cinch-Tgit>git svn clone https://cinch.svn.codeplex.com/svn
Initialized empty Git repository in c:/Codez/Temp/zSVNtest/cinch-Tgit/svn/.git/
C:\Program Files (x86)\Git\bin\perl.exe: *** unable to remap C:\Program Files (x86)\Git\lib\perl5\site_perl\5.8.8\msys\auto\SVN\_Delta\_Delta.dll to same address as parent -- 0x6E750000
      0 [main] perl.exe" 9744 sync_with_child: child 11016(0x2B8) died before initialization with status code 0x1
    222 [main] perl.exe" 9744 sync_with_child: *** child state child loading dlls
C:\Program Files (x86)\Git\bin\perl.exe: *** unable to remap C:\Program Files (x86)\Git\lib\perl5\site_perl\5.8.8\msys\auto\SVN\_Delta\_Delta.dll to same address as parent -- 0x6E750000
5088449 [main] perl.exe" 9744 sync_with_child: child 4232(0x2D4) died before initialization with status code 0x1
5088625 [main] perl.exe" 9744 sync_with_child: *** child state child loading dlls
C:\Program Files (x86)\Git\bin\perl.exe: *** unable to remap C:\Program Files (x86)\Git\lib\perl5\site_perl\5.8.8\msys\auto\SVN\_Delta\_Delta.dll to same address as parent -- 0x6E750000

Also cousins of #277 https://github.com/msysgit/msysgit/pull/245 #246

Yeah, Codeplex, I know, it's Sourceforge with (slightly) less malware but I'm just satisfying a morbid curiosity. If you want a laugh - hg convert took 2 days to drag that repo down.

[uecasm]

I had the same problem.

The current workaround to the above seems to be to rebase the DLLs to random "free" addresses until it stops complaining -- but I've noticed that sometimes it will start having problems again after having been working for a while.

Suggestion for the msysGit devs: could you try using a less brain-dead version of Perl, maybe? There are lots of native Perl distributions available for Windows.

[dscho]

@uecasm you are welcome to try.

[uecasm]

Or raise it as a bug to whoever makes the perl you're using, perhaps. I don't see why it gets upset when DLLs get loaded at clashing/different addresses anyway -- that's normal practice in Windows. It's even a security feature since Vista, and apps built with new compilers have to explicitly opt out of loading DLLs at random addresses each time.

[t-b]

See also https://github.com/msysgit/msysgit/wiki/Perl-is-too-old. The clashing addresses thing is a relict of the fork emulation in MSYS. A PR like https://github.com/msysgit/msysgit/pull/245 fixing the bug is obviously appreciated.

[uecasm]

329 is another instance of this (from someone else). It's a recurring problem that needs a better solution than running rebase.

In my case, I've just had this happen again -- it seems to reoccur randomly (usually on different DLLs each time) after rebooting my machine. (Actually on last reboot I had a different and even weirder error, though I don't recall the specifics at the moment.)

[dscho]

329 is another instance of this (from someone else). It's a recurring problem that needs a better solution than running rebase.

@uecasm so... how much time are you prepared to invest in coming up with a better solution?

[uecasm]

If I had any idea how to solve it, I would be posting a PR, not commenting on an issue. Presumably someone reading these knows how perl and/or fork work. That person is not me.

In the latest round I had this:

C:\Program Files (x86)\Git\bin\perl.exe: *** unable to remap C:\Program Files (x86)\Git\lib\perl5\5.8.8\msys\auto\Digest\MD5\MD5.dll to same address as parent -- 0x3E0000
      0 [main] perl.exe" 9976 sync_with_child: child 10588(0x194) died before initialization with status code 0x1
    505 [main] perl.exe" 9976 sync_with_child: *** child state child loading dlls
5220632 [main] perl.exe" 9976 fork_copy: linked dll data/bss pass 0 failed, 0x4D4000..0x4DBE8C, done 0, windows pid 10628, Win32 error 487

So I tried rebasing MD5.dll but I'm still getting that last error repeating forever with different numbers, and occasionally it complains about a different DLL. This is why I'm saying that rebasing doesn't seem like a solution, because it keeps changing.

[dscho]

That person is not me.

Please note that you are demanding an awful lot of an awfully qualified person.

[uecasm]

I'm not demanding anything. I'm just saying that the existing workaround for this issue is too technical for some people, only temporarily resolves the problem, and sometimes doesn't even work.

How is it "demanding" to use a bug-reporting system to report a bug? Because this IS a bug, it prevents at least "git svn" and possibly some other Perl-based commands from working as intended.

[t-b]

@uecasm AFAIK The new git for windows will have a batch file which you need to execute and then its done.

[dscho]

I'm not demanding anything.

Oh c'mon. You demanded a better solution than the current rebase.exe way. Now you can go and work on a better solution. Or you can continue demanding that others spend time for you. Your choice.

[t-b]

I just sucessfully cloned a svn repository with git svn clone using the just released new version. Please have a try.

[dscho]

Git for Windows 2.x most likely fixes this problem.

[uecasm]

FWIW, GfW 2.x 32-bit still has this problem (although it appears to be less severe), but so far at least the 64-bit version seems ok.

[dscho]

GfW 2.x 32-bit still has this problem

Please open a Git for Windows 2.x ticket, then.