-
Notifications
You must be signed in to change notification settings - Fork 316
_Delta.dll to same address as parent -- 0x6E750000 #307
Comments
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. |
@uecasm you are welcome to try. |
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. |
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 msysgit/msysgit#245 fixing the bug is obviously appreciated. |
#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.) |
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:
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. |
Please note that you are demanding an awful lot of an awfully qualified person. |
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. |
@uecasm |
Oh c'mon. You demanded a better solution than the current |
I just sucessfully cloned a svn repository with |
Git for Windows 2.x most likely fixes this problem. |
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. |
Please open a Git for Windows 2.x ticket, then. |
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 ...
Also cousins of #277 msysgit/msysgit#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.The text was updated successfully, but these errors were encountered: