git svn - error under cygwin

后端 未结 4 1964
忘掉有多难
忘掉有多难 2021-02-05 08:32

I have cygwin and git. I\'m trying to commit with git to svn - git svn dcommit. But it fails with strange error:

$ git svn dcommit
      4 [main] perl 55         


        
相关标签:
4条回答
  • 2021-02-05 08:47

    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:

    Jon,

    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):

    $ rebaseall

    $ peflagsall

    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.

    See also: http://www.spinics.net/lists/git/msg183753.html

    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.

    0 讨论(0)
  • 2021-02-05 09:03

    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, errno 11

    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:

    http://code.google.com/p/chromium/wiki/CygwinDllRemappingFailure

    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.

    c:\cygwin\bin>ash /usr/bin/rebaseall -b 0x60000000

    After restarting my cygwin shell git svn dcommit worked.

    0 讨论(0)
  • 2021-02-05 09:04

    Faced similar problems and it didnt go awway till i ran 1. rebaseall 2. perlrebase 3. peflagsall

    run them all to fix the problem

    0 讨论(0)
  • 2021-02-05 09:05

    Did you try a rebaseall like described here?

    When you are working with Cygwin, sometimes you will 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 your Cygwin windows, Execute <cygwin_home>\bin\ash.exe. It will open a new console window. Execute rebaseall there.
    Once it has completed, you can go back to running Cygwin again without any issues :-)


    The OP gor reports he had to reboot to make rebaseall work.
    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 (ps -a from ash should show nothing but ash and 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 its .dll's.

    Windows uses 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 ASLR has changed but Cygwin is holding on to an older copy (this can happen when setup doesn't complete).

    ASLR is a great defense against malware or hackers. Hackers can't constantly try new addresses for your .dll's without crashing your system.

    0 讨论(0)
提交回复
热议问题