SVN cloning seems broken

[Arioch The]

I needed to fetch SVN repo into local repo, using Win 8.1 x86

Git fails.

-------------- environment description --------

The box connects to the net via quite specific MS-authenticated Squid proxy, which many applications fail with.

So I instead set up a local no-auth proxy, that accepts local connections and deals with corporate proxy.

My devel box is totally disconnected from outer net and only can exchange with my first box via shared folders on a vetted file exchange server.

That policy is out of my influence, it is given.

So, I guess it is obvious why I need DVCS here, even when upstream library is SVN.

TortoiseSVN after being set to use this local proxy connects and fetches the repo successfully. Also views log and all that. Slow, but works.

TortoiseGit after being set to use this local proxy also operates fine with https Git repositories online.

--------------------------------------------------------

When I tried to use TortoiseGit to download https SVN repo - and it failed.

See logs at https://groups.google.com/forum/#!topic/tortoisegit-users/oWpjBtbXWvc

Surely it could be because Tortoise sets wrong environment, so today I created a fresh empty folder and run Git Bash in it.

The failure is the same as in TortoiseGit by the link above

$ git --version

git version 2.15.0.windows.1

$ git config --get http.proxy

http://localhost:8090

$ git.exe svn clone "https://svn.code.sf.net/p/tdbf/code" "D:\1\code" -T trunk - b branches -t tags

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

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

1 [main] perl 4944 child_info_fork::abort: address space needed by 'msys-s vn_wc-1-0.dll' (0x410000) is already occupied

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

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

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

....and so forth.

[Johannes Schindelin]

Hi,


please note that a better place to report bugs is the bug tracker at
https://github.com/git-for-windows/git/issues (it is much easier to keep
track of bugs there, and it is also much easier to find similar bugs,
too).

On Tue, 21 Nov 2017, Arioch The wrote:

> $ git.exe svn clone "https://svn.code.sf.net/p/tdbf/code" "D:\1\code" -T
> trunk - b branches -t tags
>
> 0 [main] perl 12028 child_info_fork::abort: unable to remap msys-svn_wc-1-
> 0.dll to same address as parent (0x410000) - try running rebaseall

> [...]

This usually indicates a conflict of the base address of the MSYS2 runtime
with other .dll files.

You *might* be able to fix this by opening a Powershell in Administrator
Mode and calling

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

See also https://github.com/git-for-windows/git/wiki/32-bit-issues (even
if this problem also occasionally shows on 64-bit systems).

Ciao,
Johannes

[Arioch The]

When possible it is better to start getting some info from people, if nothing better than just stats how many people in different environments can reproduce it.

And to confirm it is a big and not my misuse of the tool.

Registering bug is better done when the bug is confirmed and reproduced

[Arioch The]

This usually indicates a conflict of the base address of the MSYS2 runtime
with other .dll files.

Which should not be a fatal problem as dll files are made relocatable. That might slow down their first cold loading a bit (CPU is always faster than HDD anyway. But would not be a show stopper.

You *might* be able to fix this by opening a Powershell in Administrator
Mode and calling

I'll try it in cmd.exe when i get to the box.

Sad git is now installed into Program Files with all the UAC hassle it causes.

[Arioch The]

See also https://github.com/git-for-windows/git/wiki/32-bit-issues (even
if this problem also occasionally shows on 64-bit systems).

> Typically it is unnecessary to run this script manually because it is run as part of Git for Windows' installation process. If the symptom occurs at some stage long after Git for Windows was installed, reinstalling Git for Windows is the most convenient way to fix it.

Raising doubts before trying might be premature, but

1. If going away from hardcoding addresses is not possible, then maybe better would be to stripreloc the core library, so it always would be loaded to that address. And then maybe even register it as dll loaded into every process in OS instance ( would not work if there is several git installations in one box, though )

2. It is said the script is run at the installation, but as i mentioned i did intalled fresher Git after first failed attempt. So the script supposedly had run.

3. Why is there such a script, why not just ask rebase to process all exe/com/dll files? I suppose there is some fixed manually made white list of PE modules to process. Not all but some. This would also explain why other functions of git worked and only svn failed: just the module(s) missed from the script were not used by any native non-svn git functions...

[Johannes Schindelin]

Hi Arioch,

On Sun, 26 Nov 2017, Arioch The wrote:

> > See also https://github.com/git-for-windows/git/wiki/32-bit-issues (even
> > if this problem also occasionally shows on 64-bit systems).
> >
>
> > Typically it is unnecessary to run this script manually because it is run
> as part of Git for Windows' installation process. If the symptom occurs at
> some stage long after Git for Windows was installed, reinstalling Git for
> Windows is the most convenient way to fix it.

Your mail program does not quote properly, it seems.

> Raising doubts before trying might be premature, but
>
> 1. If going away from hardcoding addresses is not possible,

See
https://github.com/git-for-windows/msys2-runtime/blob/master/winsup/cygwin/how-cygheap-works.txt

> then maybe better would be to stripreloc the core library, so it always
> would be loaded to that address. And then maybe even register it as dll
> loaded into every process in OS instance ( would not work if there is
> several git installations in one box, though )

That is just one reason why that's a no-go. Registering the DLL in such a
way is 1) unnecessary for everything but MSYS2 processes, and 2) requires
administrator privileges. And 3) it may very well interfere in very
unfortunate ways with other software injecting itself (I read reports that
even graphics adapter drivers inject themselves now).

> 2. It is said the script is run at the installation, but as i mentioned
> i did intalled fresher Git after first failed attempt. So the script
> supposedly had run.

You have a 64-bit setup. The rebase script is run only in 32-bit setups
upon installation.

> 3. Why is there such a script, why not just ask rebase to process all
> exe/com/dll files? I suppose there is some fixed manually made white list
> of PE modules to process. Not all but some. This would also explain why
> other functions of git worked and only svn failed: just the module(s)
> missed from the script were not used by any native non-svn git functions...

Rebasing blindly does not necessarily prevent any other problems. There
are cases where the address contention is triggered by another software
that gets installed. The preconfigured base address is supposed to "fit
most setups".

If you are interested in working on this end, I would be very glad. But
please note that it is definitely nothing you can "quick-fix". If there
was a quick fix, it would have been found by now, as greater minds than
you and I work on Cygwin for decades already.

Ciao,
Johannes