Cannot fetch from svn repo (2.7.1 on win x64)

[CageZ]

Hello,

I have a problem with the newest release of git on windows x64 during using git svn fetch.

$ git svn fetch
      8 [main] perl 6292 child_info_fork::abort: unable to map C:\Program Files\Git\usr\bin\msys-svn_subr-1-0.dll, Win32 error 1114
     15 [main] perl 5136 child_info_fork::abort: unable to map C:\Program Files\Git\usr\bin\msys-svn_subr-1-0.dll, Win32 error 1114
     10 [main] perl 2716 child_info_fork::abort: unable to map C:\Program Files\Git\usr\bin\msys-svn_subr-1-0.dll, Win32 error 1114
     11 [main] perl 4256 child_info_fork::abort: unable to map C:\Program Files\Git\usr\bin\msys-svn_subr-1-0.dll, Win32 error 1114
     11 [main] perl 8196 child_info_fork::abort: unable to map C:\Program Files\Git\usr\bin\msys-svn_subr-1-0.dll, Win32 error 1114

I had no problems with the version befor (2.7.0.windows.1).

Thank you!

[nalla]

This information does not help at all. Please provide a MVCE.

[CageZ]

Hello nalla,

I have an old local repo on my system, which I have cloned a long time ago from svn (1.4). From time to time I update my git installation and had no problems with this svn repo to dcommit or to fetch. But with the newest release I cannot fetch anymore. I have a windows 8.1 x64.

[nalla]

Now, If I tell tell you that I have multiple svn repositories at hand to that I can easily dcommit or fetch from, I can only tell you that it works here. So unless your provide enough data so that someone else can reproduce your issue, you can not expect any help.

[CageZ]

Okay, my repo was broken since the last git svn dcommit. Sry.

[White-Tiger]

how did you find out your repo was "broken"? And how did you fix that? Because I've got the exact same issue and had to downgrade to Git-2.6.4-64-bit to get it working again...

[albertosantini]

I get the same error on Windows 8.1 64bit, executing git svn rebase.

The repo itself is ok.

I tried with:

• 2.7.1.windows.2 64bit and that error is displayed.
• 2.7.0.windows.1 64bit and it works ok.

Then I tried with:

• 2.7.1.windows.2 32bit and it works ok.

A memory address conflict? A rebase problem?

[White-Tiger]

I reinstalled 2.7.1.2 two times before I replied here.. also tried 2.7.0.2 and nothing worked... So I'll just stay at 2.6.4 for now.

[dscho]

Are any of you running this as administrator on a domain-joined machine?

[dscho]

A memory address conflict? A rebase problem?

@albertosantini possibly. You can test that by closing all Git windows, opening an administrator cmd and running these steps (please apply common sense when things do not work at once, I did not test these steps but write them out from memory):

cd C:\Program Files\Git\usr\bin
dash -c 'dash rebaseall -p'

If the git svn command works after that, your hypothesis is likely correct.

[albertosantini]

@dscho Thanks for the details about rebasing.

It seems the hypothesis is not correct. After rebasing I continue to get that error.

C:\My\Programs\Git\usr\bin>dash -c "./dash rebaseall -v -p"
rebaseall: 29: cd: can't cd to rebaseall
/usr/lib/sasl2/msys-sql-3.dll: new base = 17d750000, new size = 10000
/usr/lib/sasl2/msys-scram-3.dll: new base = 17d760000, new size = 10000
/usr/lib/sasl2/msys-sasldb-3.dll: new base = 17d770000, new size = 10000
/usr/lib/sasl2/msys-plain-3.dll: new base = 17d780000, new size = 10000
/usr/lib/sasl2/msys-otp-3.dll: new base = 17d790000, new size = 20000
/usr/lib/sasl2/msys-gssapiv2-3.dll: new base = 17d7b0000, new size = 10000
...

At the moment my workaround is git 32 bit. Fair enough.

Are any of you running this as administrator on a domain-joined machine?

@dscho At work I am machine administrator on my domain-joined machine. Why?

[dscho]

I am machine administrator on my domain-joined machine. Why?

Because I stumbled upon this link when searching for the error number: https://cygwin.com/faq-nochunks.html#faq.using.sshd-in-domain

[albertosantini]

@dscho Well, the context of that faq is completely different, but I explored the idea of permission problems.

After a few hours of investigation (paths, permissions, admin grants, reboots, etc.), I didn't get any result and I didn't get any evidence to reproduce the problem. Also the latest version, 2.7.2, just released, shows the same issue in my context.

Win32 error 1114 is a generic Windows error related to the DLL initialization.

Recap.

I have been using portable 64bit installation on Windows 8.1 64bit. Luckly with portable 32bit installation I have not any issue.

[dscho]

I have been using portable 64bit installation on Windows 8.1 64bit.

Oh! The portable Git! Did you run the post-install.bat script (implicitly run if you run the archive as self-extracting installer)?

[albertosantini]

post-install.bat runs correctly.

Indirectly I can confirm it: if I try to delete the archive just after the extraction, I cannot do it, because the script is running; to clean the folder I need to wait a few seconds. :)

However I tried to install also the release with the usual installer and I get the same error.

It seems the only solution at the moment is 32bit release.

[dscho]

Maybe running ProcMon will shed some light into the issue?

It seems the only solution at the moment is 32bit release.

Please help me figure out a fix so that 64-bit works, too.

[albertosantini]

After investigating an overhelming number of events with ProcMon, the only things I noticed is a different pattern between 32bit and 64bit.

In the 64bit there is a buffer overflow: in ProcMon domain it means there is a request of memory allocation; indeed the same call later has a SUCCESS result. However in 32bit there is not trace about this allocation.

15:13:35.5943976    perl.exe    12048   CreateFile  C:\My\Programs\Git\usr\bin\msys-svn_subr-1-0.dll    SUCCESS Desired Access: Read Data/List Directory, Execute/Traverse, Synchronize, Disposition: Open, Options: Synchronous IO Non-Alert, Non-Directory File, Attributes: n/a, ShareMode: Read, Delete, AllocationSize: n/a, OpenResult: Opened
15:13:35.5944245    perl.exe    12048   CreateFileMapping   C:\My\Programs\Git\usr\bin\msys-svn_subr-1-0.dll    FILE LOCKED WITH ONLY READERS   SyncType: SyncTypeCreateSection, PageProtection: 
15:13:35.5944473    perl.exe    12048   CreateFileMapping   C:\My\Programs\Git\usr\bin\msys-svn_subr-1-0.dll    SUCCESS SyncType: SyncTypeOther
15:13:35.5944954    perl.exe    12048   Load Image  C:\My\Programs\Git\usr\bin\msys-svn_subr-1-0.dll    SUCCESS Image Base: 0x17ece0000, Image Size: 0xef000
15:13:35.5945169    perl.exe    12048   CloseFile   C:\My\Programs\Git\usr\bin\msys-svn_subr-1-0.dll    SUCCESS 
15:13:35.5965570    perl.exe    12048   QueryNameInformationFile    C:\My\Programs\Git\usr\bin\msys-svn_subr-1-0.dll    BUFFER OVERFLOW Name: \My\Pr
15:13:35.5965769    perl.exe    12048   QueryNameInformationFile    C:\My\Programs\Git\usr\bin\msys-svn_subr-1-0.dll    BUFFER OVERFLOW Name: \My\Pr
15:13:35.5965875    perl.exe    12048   QueryNameInformationFile    C:\My\Programs\Git\usr\bin\msys-svn_subr-1-0.dll    BUFFER OVERFLOW Name: \My\Pr
15:13:35.5966077    perl.exe    12048   QueryNameInformationFile    C:\My\Programs\Git\usr\bin\msys-svn_subr-1-0.dll    BUFFER OVERFLOW Name: \My\Pr
15:13:35.5966180    perl.exe    12048   QueryNameInformationFile    C:\My\Programs\Git\usr\bin\msys-svn_subr-1-0.dll    BUFFER OVERFLOW Name: \My\Pr
15:13:35.5966305    perl.exe    12048   QueryNameInformationFile    C:\My\Programs\Git\usr\bin\msys-svn_subr-1-0.dll    BUFFER OVERFLOW Name: \My\Pr
15:13:35.5966404    perl.exe    12048   QueryNameInformationFile    C:\My\Programs\Git\usr\bin\msys-svn_subr-1-0.dll    BUFFER OVERFLOW Name: \My\Pr
15:13:35.5966507    perl.exe    12048   QueryNameInformationFile    C:\My\Programs\Git\usr\bin\msys-svn_subr-1-0.dll    BUFFER OVERFLOW Name: \My\Pr
15:13:35.5966613    perl.exe    12048   QueryNameInformationFile    C:\My\Programs\Git\usr\bin\msys-svn_subr-1-0.dll    BUFFER OVERFLOW Name: \My\Pr
15:13:35.6003698    perl.exe    12048   QueryNameInformationFile    C:\My\Programs\Git\usr\bin\msys-svn_subr-1-0.dll    SUCCESS Name: \My\Programs\Git\usr\bin\msys-svn_subr-1-0.dll
15:13:35.6004051    perl.exe    12048   QueryNameInformationFile    C:\My\Programs\Git\usr\bin\msys-svn_subr-1-0.dll    SUCCESS Name: \My\Programs\Git\usr\bin\msys-svn_subr-1-0.dll

I cannot compile the project, but it would be interesting if the issue is related to the following PRs:

• https://github.com/git-for-windows/git/pull/606
• https://github.com/git-for-windows/git/pull/612

[White-Tiger]

@albertosantini sorry that I'm not really helpful as I don't have much time to test (and I can't run ProcMon without also rebooting my system as it conflicts with any app using WinLicense) But I'm thankful for your efforts ;) Keep it up.

Since my Git is installed in E:\zZ-Progra\Git and yours isn't in the default location as well, I tried to do a "default" install with Git-2.7.2-64-bit.exe... (except for no context menu and checkout "as-is" instead of Windows) but that didn't change anything sadly..

[gregorko]

I have the same problem.. dash -c 'dash rebaseall -p' did not help. I'm now also using git 32bit and its working...

[dscho]

I have the same problem.. dash -c 'dash rebaseall -p' did not help.

Please note that mentioning that something did not help (without going into anything close to resembling any sort of detail) is not helpful in and of itself.

:smiley:

[p91paul]

Might be useful to know that git 2.7.4 on cygwin is affected by the same issue, as well as the just released git for windows 2.8.0.

[dscho]

@p91paul thank you for your feedback. Please note that debugging this issue is very involved. Any help is appreciated.

[p91paul]

Is there something (logs, debug traces, etc) I can get to help you?

[dscho]

@p91paul I am afraid that it will not be that easy to help debugging this.

When I said it is very involved, I really mean it. In order to make sense of the problem, you first have to pinpoint where things go wrong.

With MSYS2 software that typically means that you have to rebuild the software with debugging information, and frequently not only that, you also have to insert debug print statements (you need those when the stacktrace that you get after the program crashed is useless). Then you need to run the entire failing command again, trying to figure out at which debug print statement things go south. Then you need to insert more debug print statements that verify that it is there that things go south. Lather, rinse and repeat.

If you are up for some hard-core debugging, I can assist you. If not, I am afraid that this ticket will have to wait until somebody steps in and does what is required to diagnose and fix the bug.

(Side note: As the issue occurs only with large repositories, and only on 64-bit systems, it is quite possible that the culprit is something as innocuous as using some undeclared function that wants to return a pointer; I recently fixed such a bug that could cause nasty crashes on 64-bit.)

[ivan-danilov]

@dscho I have this issue stable reproducible right now. If you can direct me what to do - I will try to help.

I have git repo of just 6 files, less than 2 Mb total (though SVN repository from where one folder was cloned through git svn is quite large).

$ git --version
git version 2.7.4.windows.1

[dscho]

@ivan-danilov good! Here are the pointers:

First of all, you will want to install the Git for Windows SDK and verify that you can replicate the error.

Then you probably want to run Process Monitor while replicating the error and try to figure out from its output whether there is anything obvious going wrong (such as: symbols not found in a DLL, transitive DLL not found, etc).

If the bug is still repeatable and Process Monitor does not show anything obvious, another option would be to set the GIT_STRACE_COMMANDS environment variable to trigger fine-grained output from the MSYS2 runtime (which almost certainly produces the error messages mentioned in the initial report).

Here's hoping that you can find the root cause!

[ivan-danilov]

While installing SDK:

:: Synchronizing package databases...
error: failed retrieving file 'git-for-windows.db' from dl.bintray.com : SSL certificate problem: unable to get local issuer certificate
error: failed to update git-for-windows (download library error)
 mingw32                                                    265.8 KiB   572K/s 00:00 [###############################################] 100%
 mingw32.sig                                                 96.0   B   619B/s 00:00 [###############################################] 100%
 mingw64                                                    265.2 KiB  1551K/s 00:00 [###############################################] 100%
 mingw64.sig                                                 96.0   B   619B/s 00:00 [###############################################] 100%
 msys                                                       130.5 KiB  12.7M/s 00:00 [###############################################] 100%
 msys.sig                                                    96.0   B   592B/s 00:00 [###############################################] 100%
error: failed to synchronize all databases

There was a problem accessing the MSYS2 repositories
If your setup requires an HTTP proxy to access the web,
please specify it here, otherwise leave it empty.

We have traffic inspection at office done via internal trusted certificate, effectively man-in-the-middle. Is there a way to get all required files offline or maybe download them at home and install at office afterwards?

[ivan-danilov]

With GIT_STRACE_COMMANDS I have different results actually:

id@idanilov MINGW64 /e/test (master)
$ git svn fetch > ../log.txt 2>&1
      3 [main] perl 11128 child_info_fork::abort: unable to map C:\Program Files\Git\usr\bin\msys-svn_subr-1-0.dll, Win32 error 1114
      3 [main] perl 11180 child_info_fork::abort: unable to map C:\Program Files\Git\usr\bin\msys-svn_subr-1-0.dll, Win32 error 1114

id@idanilov MINGW64 /e/test (master)
$ cat ../log.txt
      3 [main] perl 11128 child_info_fork::abort: unable to map C:\Program Files\Git\usr\bin\msys-svn_subr-1-0.dll, Win32 error 1114
      3 [main] perl 11180 child_info_fork::abort: unable to map C:\Program Files\Git\usr\bin\msys-svn_subr-1-0.dll, Win32 error 1114

id@idanilov MINGW64 /e/test (master)
$ export GIT_STRACE_COMMANDS=1

id@idanilov MINGW64 /e/test (master)
$ git svn fetch > ../log.txt 2>&1
11200503 [main] perl 8236 fork: child 12760 - died waiting for dll loading, errno 11

id@idanilov MINGW64 /e/test (master)
$ git svn fetch > ../log.txt 2> ../logerr.txt
11161900 [main] perl 9640 fork: child 10876 - died waiting for dll loading, errno 11

id@idanilov MINGW64 /e/test (master)
$ cat ../logerr.txt
11161900 [main] perl 9640 fork: child 10876 - died waiting for dll loading, errno 11
open2: fork failed: Resource temporarily unavailable at /mingw64/share/perl5/site_perl/Git.pm line 411.

Not sure, possibly it is the result of SDK absence maybe?

[p91paul]

I can add the perl stacktrace obtained with Carp.cluck

Am I dying? at /mingw64/share/perl5/site_perl/Git.pm line 411.
    Git::command_bidi_pipe(Git=HASH(0x600f25b20), "hash-object", "-w", "--stdin-paths", "--no-filters") called at /mingw64/share/perl5/site_perl/Git.pm line 995
    Git::_open_hash_and_insert_object_if_needed(Git=HASH(0x600f25b20)) called at /mingw64/share/perl5/site_perl/Git.pm line 971
    Git::hash_and_insert_object(Git=HASH(0x600f25b20), ".git/Git_svn_delta_33892_34_nyScQd") called at /mingw64/share/perl5/site_perl/Git/SVN/Fetcher.pm line 419
    Git::SVN::Fetcher::close_file(Git::SVN::Fetcher=HASH(0x6004ba220), HASH(0x601401e78), "ba6b7b4779504802b52a7b4ef949acf6", _p_apr_pool_t=SCALAR(0x601496650)) called at /usr/lib/perl5/vendor_perl/SVN/Ra.pm line 623
    SVN::Ra::Reporter::AUTOLOAD(SVN::Ra::Reporter=ARRAY(0x60123d410), SVN::Pool=REF(0x6005601d0)) called at /mingw64/share/perl5/site_perl/Git/SVN/Ra.pm line 312
    Git::SVN::Ra::gs_do_update(Git::SVN::Ra=HASH(0x60007c038), 1053268, 1053268, Git::SVN=HASH(0x60108ebc0), Git::SVN::Fetcher=HASH(0x6004ba220)) called at /mingw64/share/perl5/site_perl/Git/SVN.pm line 1205
    Git::SVN::do_fetch(Git::SVN=HASH(0x60108ebc0), HASH(0x60123d4b8), 1053268) called at /mingw64/share/perl5/site_perl/Git/SVN/Ra.pm line 475
    Git::SVN::Ra::gs_fetch_loop_common(Git::SVN::Ra=HASH(0x60007c038), 1053268, 1053268, ARRAY(0x600791bf0), ARRAY(0x600791c08)) called at /mingw64/share/perl5/site_perl/Git/SVN.pm line 179
    Git::SVN::fetch_all("svn") called at D:\git-sdk-64\mingw64/libexec/git-core\git-svn line 522
    main::cmd_clone("https://svn.apache.org/repos/asf/excalibur/trunk/", "foo_excal") called at D:\git-sdk-64\mingw64/libexec/git-core\git-svn line 386
    eval {...} called at D:\git-sdk-64\mingw64/libexec/git-core\git-svn line 384
31434510 [main] perl 33892 fork: child 18016 - died waiting for dll loading, errno 11 
open2: fork failed: Resource temporarily unavailable at /mingw64/share/perl5/site_perl/Git.pm line 412.

Obviously the fork failed message moved to line 412 because on line 411 there was a

cluck "Am I dying?";

So it dies calling git hash-object -w --stdin-path --no-filters

[dscho]

We have traffic inspection at office done via internal trusted certificate, effectively man-in-the-middle. Is there a way to get all required files offline or maybe download them at home and install at office afterwards?

This looks more like the ssl-certificates package was not correctly installed when I built the SDK. Just to make sure: you are using 64-bit Git for Windows SDK 1.0.3?

11161900 [main] perl 9640 fork: child 10876 - died waiting for dll loading, errno 11

This probably means that already the strace.exe binary could not be loaded properly. Which I guess indicates some resource problem of some sorts: strace.exe is already an MSYS2 program, hence it suffers the same problem as the previously reported one.

So it dies calling git hash-object -w --stdin-path --no-filters

Right, and as git hash-object is a builtin written in C, i.e. no perl is involved at all, and as the error message mentions that the perl process dies, it means that somehow the process cannot even be spawned.

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

The second error simply translates the EAGAIN produced by the first error into English. The first error is produced by this code in the MSYS2 runtime:

  /* Start thread, and then wait for it to reload dlls.  */
  resume_child (forker_finished);
  if (!ch.sync (child->pid, hchild, FORK_WAIT_TIMEOUT))
    {
      this_errno = EAGAIN;
      error ("died waiting for dll loading");
      goto cleanup;
    }

So here we are diving deep down into Cygwin internals (keep in mind that the MSYS2 runtime we use is a close fork of the Cygwin runtime, so all the same caveats apply).

The thing here is that POSIX has no spawn() syscall. This is too bad, and to make things worse, everybody and their dog has to emulate it using the fork() syscall (which makes a complete copy-on-write copy of the memory and the open file descriptors and stuff, which is stupid in this case because all we want to do is to throw all of that away anyway by using the exec() call to complete the spawn() emulation).

The code you are seeing here is the last part of Cygwin's fork() emulation, where it spins up a completely separate process and copies the relevant parts of the memory and reopens the file descriptors. We are looking at the caller, just after it told the child process to do all that, so now it just wants to sit and wait until the child process completed its part of the fork() emulation.

And it is here that things apparently go wrong.

Since the timeout is 300 seconds (i.e. 5 minutes), and since no such delay was reported, I will just go ahead and assume that the problem is something else than the reported timeout during DLL loading (which is only a best guess on the error message's part, anyway).

So here is the code of the sync method:

bool
child_info::sync (pid_t pid, HANDLE& hProcess, DWORD howlong)
{
  bool res;
  HANDLE w4[2];
  unsigned n = 0;
  unsigned nsubproc_ready;

  if (!subproc_ready)
    nsubproc_ready = WAIT_OBJECT_0 + 3;
  else
    {
      w4[n++] = subproc_ready;
      nsubproc_ready = 0;
    }
  w4[n++] = hProcess;

  sigproc_printf ("n %d, waiting for subproc_ready(%p) and child process(%p)", n, w4[0], w4[1]);
  DWORD x = WaitForMultipleObjects (n, w4, FALSE, howlong);
  x -= WAIT_OBJECT_0;
  if (x >= n)
    {
      system_printf ("wait failed, pid %u, %E", pid);
      res = false;
    }
  else
    {
      if (x != nsubproc_ready)
    {
      res = false;
      GetExitCodeProcess (hProcess, &exit_code);
    }
      else
    {
      res = true;
      exit_code = STILL_ACTIVE;
      if (type == _CH_EXEC && my_wr_proc_pipe)
        {
          ForceCloseHandle1 (hProcess, childhProc);
          hProcess = NULL;
        }
    }
      sigproc_printf ("pid %u, WFMO returned %d, exit_code %y, res %d", pid, x,
              exit_code, res);
    }
  return res;
}

My best suggestion would be to rebuild the MSYS2 runtime with all of these *_printf() calls converted to small_printf() (so that the messages are not only printed when executed with strace.exe, but always), and then run the failing program again.

My hunch is that the problem might have something to do with running out of file descriptors, maybe because no-longer-needed ones were not closed properly.

[ivan-danilov]

This looks more like the ssl-certificates package was not correctly installed when I built the SDK. Just to make sure: you are using 64-bit Git for Windows SDK 1.0.3?

That's right.

I captured what is going on in procmon for all processes under bash.exe process tree. You can take a look at https://www.dropbox.com/s/hsnct0i4of4jsx9/GIT-SVN.ZIP?dl=0 - not sure it helps much, but Process Tree view looks somewhat promising - shows what was executed at a timeline. I believe each of the last three perl.exe processes (separated by a large time amounts, probably went to error handling) printed an error message. P.S. That was without GIT_STRACE_COMMANDS, so these are perl 8956 child_info_fork::abort: unable to map C:\Program Files\Git\usr\bin\msys-svn_subr-1-0.dll, Win32 error 1114 errors

[dazinator]

I am not going to be of much use here, but just wanted to say I am experiencing this problem on Windows 10, x64, with versions:

• 2.8.1.windows.1 and the most recent 2.9.0

When doing a git svn clone --stdlayout - it leads to:

45 [main] perl 15880 child_info_fork::abort: unable to map C:\Users\darrell
.tunnell\AppData\Local\Programs\Git\usr\bin\msys-svn_subr-1-0.dll, Win32 error 1
114
open2: fork failed: Resource temporarily unavailable at /mingw64/share/perl5/sit
e_perl/Git.pm line 411.

I have confirmed that the 'dll' msys-svn_subr-1-0.dll does exist at the location mentioned. A quick google of Win32 error 1114 says it's:

ERROR_DLL_INIT_FAILED
1114 (0x45A)
A dynamic link library (DLL) initialization routine failed.

I've heard also that this problem is only on x64 and not x32. Call me stupid but could this be something to with an X64 binary being loaded into a 32bit process or vica versa?

[dazinator]

Confirmed that uninstalling the x64 version of 2.9.0 and installing the x32 bit bit version - it now works. In my extraordinarily simple mind (being a .NET developer not often if ever dealing with native development) - this lends credence to the idea that msys-svn_subr-1-0.dll is not compatible with the x64 process, or perhaps an x32 bit process is being spawned and you are attempting to load an x64 binary (msys-svn_subr-1-0.dll) into it? Just a complete guess.

[dazinator]

~Was just wondering if the msys-svn_subr-1-0.dll is something that is only used for the x64 bit version, because after uninstalling and then installing the x32 bit version (2.9.0) I can now longer find this assembly on my machine anywhere. With the x64 install it was located at: C:\Users\darrell .tunnell\AppData\Local\Programs\Git\usr\bin\msys-svn_subr-1-0.dll ~ My bad. In 1.9.0 this assembly is now placed under C:/Program Files/Git/user or C:/Program Files (x86)/Git/user for x64 and x86 installs respectively.

[dscho]

@dazinator you could try to replace the files in question with the versions from https://github.com/dscho/MSYS2-packages/releases/tag/subversion-1.9.4-2 and test again. There is a known breakage for which we try to get a fix into the official subversion package of MSYS2.

[dazinator]

@dscho - Just tried replacing the binaries from the x64 install of 1.9.0 with the ones from the releae you linked to subversion-1.9.4-2-x86_64.pkg.tar.xz and this yields the identical error still.

However I think there are 2 different versions of msys-svn_subr-1-0.dll in play here, because if I take the msys-svn_subr-1-0.dll from the 32 bit install of 1.9.0 and copy it over the one installed by the x64 install of 1.9.0 I get a different error:

E:\mig\mig>git svn clone --stdlayout --authors-file=authors.txt https://skydev01
.dvcsales.co.uk/svn/Reach.GlobalConnect2 GC2-Website
Can't load '/usr/lib/perl5/vendor_perl/auto/SVN/_Core/_Core.dll' for module SVN:
:_Core: Exec format error at /usr/lib/perl5/core_perl/DynaLoader.pm line 193.
  at /usr/lib/perl5/vendor_perl/SVN/Base.pm line 59.
BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/SVN/Core.pm line
 5.
Compilation failed in require at /mingw64/share/perl5/site_perl/Git/SVN/Utils.pm
 line 6.
BEGIN failed--compilation aborted at /mingw64/share/perl5/site_perl/Git/SVN/Util
s.pm line 6.
Compilation failed in require at /mingw64/share/perl5/site_perl/Git/SVN.pm line
32.
BEGIN failed--compilation aborted at /mingw64/share/perl5/site_perl/Git/SVN.pm l
ine 32.
Compilation failed in require at C:\Program Files\Git\mingw64/libexec/git-core\g
it-svn line 21.
BEGIN failed--compilation aborted at C:\Program Files\Git\mingw64/libexec/git-co
re\git-svn line 21.

I noticed in the package 1.9.4-2-x86_64.pkg.tar.xz there is only a single msys-svn_subr-1-0.dll which I am guessing is the one distrubted with the x64 install, however do you have a release / package with the libs that are installed by the x32 installer? Because I'd like to take all of those and overwrite the ones in the x64 install to see if that works.

Hopefully I am making sense here, like I say I don't usually deal with native stuff.

[dazinator]

@dscho - actually I should just be able to grab them all from an x32 bit 1.9.0 install.. I'll try that

[dazinator]

Ok I got to stop - because I have absolutely no idea what I am doing, with my maverick and reckless actions :)

To summarise what I have established:-

1. x64 installer has this issue, error suggests msys-svn_subr-1-0.dll cannot be loaded.
2. x32 bit installer works fine.
3. The msys-svn_subr-1-0.dll in the x32 bit versus the x64 bit installer appear to be different because swapping them out causes a different exception.
4. Taking the libs from https://github.com/dscho/MSYS2-packages/releases/tag/subversion-1.9.4-2 and pasting them over the x64 bit installed libs results in the identical exception.

My suspicion is msys-svn_subr-1-0.dll is not compatible with the process. But without any technical knowledge of git for windows or mysysgit I can't proceed any further. If this helps someone better than I fix the problem then it would have been worth it.

[dscho]

Yeah, you cannot mix and match 32-bit and 64-bit versions: 64-bit perl will not be able to use 32-bit .dll files and vice versa.

The problem you reported is most likely the dreaded DLL base address problem.

[dazinator]

@dscho is it possible for the 64bit version of git for windows, to use a 32 bit version of pearl and thus the working 32 bit perl dll's do you think? Just throwing it out there because I am in complete ignorance of the code base and everything about it. Guessing this is probably a big no-no

[dazinator]

Also can this issue be re-opened? Or is this a duplicate?

[dazinator]

Nevermind looks like this issue is superceded by https://github.com/git-for-windows/git/issues/708