git-svn not able to clone from specific repository location

[ninevoltbatterie]

• I was not able to find an open or closed issue matching what I'm seeing

Setup

• Which version of Git for Windows are you using? Is it 32-bit or 64-bit?

$ git --version --build-options
git version 2.15.1.windows.2
built from commit: 5d5baf91824ec7750b103c8b7c4827ffac202feb
sizeof-long: 4
machine: x86_64

• Which version of Windows are you running? Vista, 7, 8, 10? Is it 32-bit or 64-bit?

Windows 7 64-bit

$ cmd.exe /c ver

Microsoft Windows [Version 6.1.7601]

• What options did you set as part of the installation? Or did you choose the
  defaults?

$ cat /etc/install-options.txt

Editor Option: VIM
Path Option: BashOnly
SSH Option: OpenSSH
CURL Option: OpenSSL
CRLF Option: CRLFCommitAsIs
Bash Terminal Option: MinTTY
Performance Tweaks FSCache: Enabled
Use Credential Manager: Enabled
Enable Symlinks: Enabled

• Any other interesting things about your environment that might be related
  to the issue you're seeing?

None I can think of.

Details

I've been using git-svn with a large Subversion repository. Recently the repository was moved to a new location on a new server with the same host name as the old server. Having run into problems trying to adjust the location, I'm just trying to do a fresh clone from the new location.

• Which terminal/shell are you running Git from? e.g Bash/CMD/PowerShell/other

git-bash.

• What commands did you run to trigger this issue?

git svn clone <SVN repository> .

• What did you expect to occur after running these commands?

I expected to get a working copy of that location.

• What actually happened instead?

1 [main] perl 8488 fork: child 11160 - died waiting for dll loading, errno 11
open2: fork failed: Resource temporarily unavailable at /mingw64/share/perl5/site_perl/Git.pm line 412.

But when I try cloning a branch from the same server, it succeeds. In fact, I've tried cloning a couple of subdirectories within the root that I actually want, and those also succeeded. By "succeed", I mean it started populating its database in .git/. I interrupted this because of the size of the repository, so I haven't actually seen a working copy yet, but at least in these other locations, it gets started.

So somehow the error depends on the content/source of the repository. A coworker has made the same observations, and had never used git-svn with this repository before it was relocated.

• If the problem was occurring with a specific repository, can you provide the
  URL to that repository to help us with testing?

It's a private repository.

[dscho]

I was not able to find an open or closed issue matching what I'm seeing

There are at least a handful tickets that are almost certainly describing the very same issue: https://github.com/git-for-windows/git/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+%22died+waiting+for+dll+loading%2C+errno+11%22

So I am marking this as a duplicate of #650.

The common work-around seems to be to use 32-bit Git for Windows.

[ninevoltbatterie]

I did look through those tickets, but didn't think they were related to my problem:

1. Git bash crashes, other git commands throw "CreateProcessW failed" and "errno 11"  #1370 says git bash crashes, and that the git command line tools don't work. It says e.g. git stash throws errors, which mine doesn't. I can use a lot of stuff in git bash, the only problems I have are ones dealing with this particular path in this particular repository.

2. The error messages in Git bash crashes, other git commands throw "CreateProcessW failed" and "errno 11"  #1370 and Windows 10 - bash.exe: fatal error in forked process - MapViewOfFileEx, Win32 error 5.  #1244 include messages that I don't get, e.g. "MapViewOfFileEx '(null)'(0x54), Win32 error 5". I see no mention of "MapViewOfFileEx".

3. The error message in Cannot fetch from svn repo (2.7.1 on win x64) #650 includes "unable to map", which doesn't appear in my error message.

4. None of those descriptions included clone working fine for some paths in the same repository, while failing for another. This is a key difference between the behavior I see and the other tickets I saw.

5. Despite that, I did try the common work-around you mention, and tried it with 32-bit Git for Windows. I got a different error ("unable to remap msys-svn_wc-1-0.dll to same address as parent ... try running rebaseall), for which one workaround seems to be to run 64-bit Git for Windows. Then I got stuck in an infinite loop doing workarounds for workarounds.

In summary, I don't think this is a duplicate of #650.

[ninevoltbatterie]

Is this ticket dead now that it was deemed a duplicate and closed? I would like to appeal that decision, but I don't know if anybody will see my comments now that this ticket is closed. If I'm wrong and it is a duplicate, I'd like to hear why I'm mistaken. I'm new to github and don't see a way to send a message to @dscho, who closed the ticket.

[dscho]

"unable to remap msys-svn_wc-1-0.dll to same address as parent ... try running rebaseall

@ninevoltbatterie this is actually an issue that should be addressed by default in the installer. If you still experience this after reinstalling the 32-bit version, I would be interested in knowing more about this, as rebaseall (which is run as part of the 32-bit installer) should fix this issue.

As to the specifics of the error message: I am rather convinced that the problem shows up only under certain circumstances, which means that it could possibly occur at different points in the execution, resulting in different specific error messages.

What makes me believe that? There have been a few bugs in the past that have bitten us, where simple erroneous casts (e.g. void * to unsigned long) caused important bits to be lost. I suspect more of the same.

[dscho]

(And sorry for the delay in answering: I started commenting, but got interrupted, my computer rebooted, and I was able to finish the comment only a few moments ago.)

[ninevoltbatterie]

@dscho When I tried the 32-bit version of Git for Windows, I just installed it alongside my existing 64-bit install. Do I need to have uninstalled the 64-bit version first?

I'd be happy with that workaround, but I remain unconvinced that the problem I'm seeing with my 64-bit is the same as the others had, since I can clone from my repository (if I only choose a subdirectory) and do all sorts of other client-side actions with my git repository.

[dscho]

When I tried the 32-bit version of Git for Windows, I just installed it alongside my existing 64-bit install. Do I need to have uninstalled the 64-bit version first?

32-bit Git for Windows should just uninstall any previous Git for Windows, whether 32-bit or 64-bit. It is possible that it does not, and maybe that causes problems in and of itself.

What I would suggest instead, if you need 32-bit Git for Windows only sporadically (or only for specific use cases) is to use a portable Git. They don't install into the Start Menu, and therefore can easily be installed side by side. That is exactly what I use to verify bugs in older versions: I have portable versions of them, allowing me to easily check whether I can reproduce an issue, and also whether any such issue is gone in newer versions.

I remain unconvinced that the problem I'm seeing with my 64-bit is the same as the others had, since I can clone from my repository (if I only choose a subdirectory) and do all sorts of other client-side actions with my git repository.

The problems in git svn we investigated successfully in the past looked like this: a pointer was cast to an unsigned long (which works as expected on 64-bit and 32-bit Linux and macOS, because unsigned long has the same size as a pointer: on 32-bit, it is 32-bit, on 64-bit, it is 64-bit). On Windows, unsigned long is 32-bit. Whether you're on 32-bit Windows or 64-bit Windows, does not matter. Naturally, this meant that some bits could be lost if the pointer used more than 32 bits. And this is where the flakiness comes from: by default, applications' memory starts somewhere in the lower 2-3GB, or even lower, in the first gigabyte. Depending which and how many .dll files you load, malloc()ed data may go higher than 4GB or not. It really depends on a lot of circumstances. If data goes higher than that, and a pointer to said data is cast to unsigned long, and then cast back, you get those strange errors.

I even had one case in the past where there was no explicit cast. The appropriate .h file was not included, so a return value of int was assumed, cutting off everything above 32-bit. Even worse: this was in Windows-specific code, so naturally the bug was not caught anywhere else.

This is what I suspect to happen in pretty much all of the git svn issues in Windows. I have yet to see one that is different.

[ninevoltbatterie]

@dscho Thank you for elaborating.

I tried portable, and got this (which I've seen in other tickets, and I tried running git-bash as administrator):

mkdir: cannot change permissions of '/dev/shm': Permission denied
mkdir: cannot change permissions of '/dev/mqueue': Permission denied

Trying to clone the repository anyway resulted in:

 0 [main] perl 11040 child_info_fork::abort: address space needed by 'msys-svn_wc-1-0.dll' (0x20B0000) is already occupied
 0 [main] perl 8516 child_info_fork::abort: address space needed by 'msys-svn_wc-1-0.dll' (0x20B0000) is already occupied

Rather than go down that road, I uninstalled both the 32 and 64-bit versions I had, then reinstalled the 32-bit version. I opened git-bash (as administrator), didn't get the mkdir errors, but got the following when I tried to do my "git svn clone":

1 [main] perl 3744 child_info_fork::abort: unable to remap msys-svn_wc-1-0.dll to same address as parent (0x2DF0000) - try running rebaseall
1 [main] perl 8708 child_info_fork::abort: unable to remap msys-svn_wc-1-0.dll to same address as parent (0x2DF0000) - try running rebaseall

[dscho]

I tried portable, and got this (which I've seen in other tickets, and I tried running git-bash as administrator):

mkdir: cannot change permissions of '/dev/shm': Permission denied
mkdir: cannot change permissions of '/dev/mqueue': Permission denied

Sorry, these are really warnings, and I keep meaning to shut them off.

reinstalled the 32-bit version. I opened git-bash (as administrator), didn't get the mkdir errors, but got the following when I tried to do my "git svn clone":

1 [main] perl 3744 child_info_fork::abort: unable to remap msys-svn_wc-1-0.dll to same address as parent (0x2DF0000) - try running rebaseall
1 [main] perl 8708 child_info_fork::abort: unable to remap msys-svn_wc-1-0.dll to same address as parent (0x2DF0000) - try running rebaseall

This should be addressed as part of the installer (see https://github.com/git-for-windows/git/wiki/32-bit-issues for details). Can you try running rebaseall (as described on that wiki page) manually?

[ninevoltbatterie]

OK, I tried running that but got output I can't even really decipher:

C:\Program Files (x86)\Git>usr\bin\dash -c '/usr/bin/dash /usr/bin/rebaseall -p'

: not foundbaseall: 2: /usr/bin/rebaseall:
: not foundbaseall: 25: /usr/bin/rebaseall:
/usr/bin/rebaseall: 29: cd: can't cd to /usr/bin
: not foundbaseall: 30: /usr/bin/rebaseall:
: not foundbaseall: 41: /usr/bin/rebaseall:
: not foundbaseall: 44: /usr/bin/rebaseall: {
 [-b BaseAddress] [-o Offset] [-s DllSuffix] [-T FileList | -] [-4|-8] [-p] [-t]
 [-i] [-v]

Also, the instructions say, "terminate even background processes that use the MSYS2 runtime, such as ssh-agent". I use another installation of cygwin on my PC, too. Could that be getting in the way? I do close it before trying any of this, but is there a way to be sure I've ended all the necessary processes?

[dscho]

: not foundbaseall: 2: /usr/bin/rebaseall:

Is this running in an elevated CMD?

Also, the instructions say, "terminate even background processes that use the MSYS2 runtime, such as ssh-agent". I use another installation of cygwin on my PC, too.

That's Cygwin. Not MSYS2.

[ninevoltbatterie]

Is this running in an elevated CMD?

Yes. I ran it with "Run as administrator". The title bar on the CMD window says "Administrator: C:\Windows\System32\cmd.exe".

[dscho]

Can you call dash with -x to trace the execution a bit more?