Git: Perl crash during svn clone

[uecasm]

While trying to git svn clone a large private repository using Git-2.4.5.1-4th-release-candidate-64-bit, it gets some way through the initial fetch and then crashes with:

  0 [main] perl 12640 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump

The dumpfile contains the following:

Exception: STATUS_ACCESS_VIOLATION at rip=0048360C537
rax=00000006020E4908 rbx=000000005219E248 rcx=000000060003A540
rdx=0000000000000000 rsi=000000000000F4FD rdi=0000000000000004
r8 =0000000000000000 r9 =0000000000000000 r10=0000000000240000
r11=000000048D785FBA r12=0000000000000003 r13=000006FFFFE8A800
r14=0000000601FFAB20 r15=000006FFFFE8A818
rbp=000000000007A7F0 rsp=000000000023BDE0
program=C:\Program Files\Git\usr\bin\perl.exe, pid 12640, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B

I realise this is probably not directly helpful because I can't share the repo so you can't directly reproduce it, but I'm not sure how to diagnose this further. Note that a colleague on a different PC using Git-2.4.6-5th-release-candidate-64-bit is getting similar crashes.

[nalla]

This is not windows specific. Even under _linux_ if the repository is large enough, git-svn will fail. try calling successive git svn fetch calls to continue.

[uecasm]

A few other things that are possibly of interest:

1. I'm using the -r nnnnn:HEAD option (where nnnnn is from a day or two ago) to clone in order to produce an abbreviated history -- as a result the first commit it imports is quite large, and it's crashing during this first revision import, so successive calls don't help.
2. Running the same clone operation using Git-2.4.6-5th-release-candidate-32-bit resulted in the following crash dump (also I still had to rebase several SVN DLLs before it would run at all):

Exception: STATUS_ACCESS_VIOLATION at eip=64B0CC7F eax=81CDF488 ebx=521BA170 ecx=FFFDF000 edx=00000000 esi=00066E44 edi=FFD76E50 ebp=FFD76E50 esp=0028C380 program=C:\Program Files (x86)\git\usr\bin\perl.exe, pid 17404, thread main cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B Stack trace: Frame Function Args End of stack trace

1. At some previous time (about 9 months and 10,000 SVN revisions ago) a similar clone on the same repository succeeded, while using GfW 1.9.5.

[nalla]

I'm using the -r nnnnn:HEAD option (where nnnnn is from a day or two ago) to clone in order to produce an abbreviated history -- as a result the first commit it imports is quite large.

That large commit is most probably the cause. The change set is so big that the data perl.exe is trying to analyze does not fit into the memory it can allocate.

[uecasm]

Shouldn't it work on the 64-bit version then? Memory limits shouldn't be an issue there.

---

Hmm. So I tried doing a clone from the same earlier rev# as 9 months ago, and it seemed to run for a lot longer before finally crashing (still during the first commit though). There were 4 perl processes and only one of them was using memory, but even that peaked at only 90 MB or so, so it doesn't seem likely that memory exhaustion would be the culprit.

It bothers me that a Perl script can cause Perl itself to crash without a useful backtrace, though.

Exception: STATUS_ACCESS_VIOLATION at eip=64B0CC7F
eax=848D3F20 ebx=521BA170 ecx=FFFDF000 edx=00000000 esi=00172FD4 edi=FFA72FE0
ebp=FFA72FE0 esp=0028C380 program=C:\Program Files (x86)\git\usr\bin\perl.exe, pid 16980, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame     Function  Args
End of stack trace

Since the EIP values seem to be the same in all crashes (on the same version, of course), I took a look at the base addresses; apparently that EIP is in _Delta.dll, in case that helps.

[dscho]

Sorry, without any way to reproduce here, there is nothing I can do.

[uecasm]

According to a debugger, the crashing IP is at:

C:\Program Files (x86)\git\usr\lib\perl5\vendor_perl\auto\SVN\_Delta\_Delta.dll
_Delta!wrap_svn_txdelta_apply+0x1cf

And now I've completely run out of ideas of ways to help track this down.

[dscho]

I really think that the only way forward here is to give somebody with strong debugging fu (and enough time, so do not look at me) access to said repository.

[dscho]

C:\Program Files (x86)\

And didn't you intend to use the 64-bit version of Git for Windows?

[nalla]

Do you have files like Git_git_blob_xxxx_x_xxxxxx or Git_svn_delta_xxxx_x_xxxxxx in your .git folder?

[uecasm]

And didn't you intend to use the 64-bit version of Git for Windows?

Yes, but as I mentioned earlier I tried switching to the 32-bit version to see if it helped with this. It didn't, but I haven't switched back yet in order to keep the crash traces consistent.

In theory that symbol trace above might be enough to give a hint to whoever built the SVN DLLs that you're using, if you can tell them which build was used in that particular GfW release. I realise there's probably not much else you can do without a way to reproduce it. (I tried finding a big public repository and seeing if a similar command crashes it, but no such luck yet. Big repos seem hard to find.)

Do you have files like Git_git_blob_xxxx_x_xxxxxx or Git_svn_delte_xxxx_x_xxxxxx in your .git folder?

Yes, they (and a Git_svn_hash file) exist while it's downloading and seem to occasionally have contents, but when it crashed they still exist but seem to be empty.

[uecasm]

Well, hey. It took quite a long time to get there, but running this command did indeed cause a crash. Perhaps this will be reproducable?

git svn clone -r 1400000:HEAD --prefix=origin/ svn://anonsvn.kde.org/home/kde/trunk kde

Still on Git-2.4.6-5th-release-candidate-32-bit (not that it seems to make much difference).

Exception: STATUS_ACCESS_VIOLATION at eip=64B0CC7F
eax=818923A8 ebx=521BA170 ecx=FFFDE000 edx=00000000 esi=0004A2DC edi=FFE4A2E8
ebp=FFE4A2E8 esp=0028C3D0 program=C:\Program Files (x86)\git\usr\bin\perl.exe, pid 8684, thread main
cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame     Function  Args
End of stack trace

cding into the directory and running git svn fetch -r 1400000:HEAD does start it running again, but I'm not sure whether it's resuming where it left off or whether it's starting again.

[dscho]

I'm not sure whether it's resuming where it left off or whether it's starting again.

As pointed out by @nalla, it is safe to fetch after an access violation.

[dscho]

Still no way to reproduce, eh?

[maoueh]

@dscho Facing a similar issue today trying to git svn fetch url svn://sourceware.org/svn/kawa.The initial clone was performed using 1.9.5 version and now, trying to sync it with version 2.5.0 64 bits.

Got 0 [main] perl 12640 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump at multiple times during git svn fetch and they always recovered at second attempt.

Now, I'm stuck at revision r8526 and git svn fetch simply always crash on revision r8527. Strange thing is sometimes for this commit I get crash dump message, and other time I get this one:

Connection timed out: Error retrieving REPORT: Connection timed out at /mingw64/share/perl5/site_perl/Git/SVN/Ra.pm line 308.

Tried to reproduce with:

git svn clone -r 8526:8528 --prefix=origin/ svn://sourceware.org/svn/kawa/trunk kawa

But this is working as expected. I will launch a full clone using newer 2.5.0 version to see if it works. Cannot start it right now, probably tonight on another computer.

I could upload my full working copy to see if you can reproduce using it if you want. I want to investigate further the crash dump but don't have time right now. Hoping to find a slot next week. Any hints one debugging this?

Extra info just in case:

• Windows 7 x86_64
• Git for Windows 2.5.0.windows1 (installed inside a MSYS2 proper)
• SVN 1.8.13
• Perl 5.22.0

[uecasm]

@dscho My last reply was a reproduction recipe. I'm not sure what more you want.

[dscho]

Well, hey. It took quite a long time to get there, but running this command did indeed cause a crash. Perhaps this will be reproducable?

git svn clone -r 1400000:HEAD --prefix=origin/ svn://anonsvn.kde.org/home/kde/trunk kde

@uecasm Well, it is _kind_ of a reproduction recipe. The first time I ran it, it crashed after 2m31s, just after adding tests/katetests/regression/tests/indent/ruby/array/array18.txt-script. The second time, it ran for a whopping 10m24 and stopped just after adding ww/sites/www/docbook/xsl-1.65.1/params/preface.autolabel.xml.

I have no doubt that there is some problem, but how would I know whether I fixed it? Is it just taking longer than usual? Did I just paper over the issue?

What I really hoped for was something like a regression test, like https://github.com/git-for-windows/git/blob/master/t/t9100-git-svn-basic.sh, that produces a local Subversion repository (maybe with _huge_ files, or with a _lot_ of files, whatever it takes to reproduce the problem) and that can be tuned to trigger the bug faster.

[maoueh]

Here my findings on this issue. In the end, I'm not sure anymore this is the same problem as original author, but I might be wrong.

By using a local svn mirror, I'm not facing the issue. By using svn://sourceware.org/svn/kawa, I'm not facing the issue. However, old clone was using http://sourceware.org/svn/kawa. So I think my crash is related to a rather big commit and a fragile connection via http.

Here (hopefully) reproducible steps (full steps with own svn to git clone in postscript-um at the end of post):

mkdir -p /tmp/git-svn-crash
cd /tmp/git-svn-crash

# Pre-built svn to git repository up to revision 8526 from a local svn mirror (76 Mb)
# Download from http://www.filedropper.com/git and save in folder as `git.zip`
# I also uploaded it to Google Driver and can share link privately if needed
unzip git.zip

cd git
git config --local svn-remote.svn.url http://sourceware.org/svn/kawa
git svn fetch
# Crash or time out

Since sometimes I get a crash and sometimes a connection timeout, they might be highly related in the end. For example, due to long time taken by git when converting commits, the HTTP connection is closed by remote end and sometimes it make perl crash. Other time, it make it display the timeout error.

Matt

P.S. Full steps if you want to do you own svn clone (i.e. without download the pre-built svn to git metadata I uploaded). In case pre-built repository is not accessible anymore or you prefer having your to do svn to git clone yourself.

Doing a direct clone (i.e. using for example svn://sourceware.org/svn/kawa) always failed with some errors about not being able to fetch a particular branch: Network connection closed unexpectedly: Unable to connect to a repository at URL 'svn://sourceware.org/svn/kawa/branches/Winternet' at /mingw64/share/perl5/site_perl/Git/SVN.pm line 1154. That's why I first do a local SVN mirror and then do a git svn clone from this local url which always worked correctly

mkdir -p /tmp/git-svn-crash
cd /tmp/git-svn-crash

svnadmin create svn
printf '#!/bin/sh\nexit 0;\n' > /tmp/git-svn-crash/svn/hooks/pre-revprop-change
svnsync init file:///tmp/git-svn-crash/svn svn://sourceware.org/svn/kawa
svnsync sync file:///tmp/git-svn-crash/svn
# Around 45 minutes

git svn clone -s -r 1:8526 file:///tmp/git-svn-crash/svn git
# Around 180 minutes, uploaded to

cd git
git config --local svn-remote.svn.url http://sourceware.org/svn/kawa
git svn fetch
# Crash or time out

[uecasm]

If it exits with an error instead of crashing with an access violation, it's a different issue. And the original issue was reproducible with the svn:// protocol.

[maoueh]

Sometimes it's an access violation, other times it's a simpler error message. So, it's both :)

As I already said, its possible both issue are different. On the other side, the crash might be triggered by the same code path withinperl.exe` because both handle big commits. Fixing the reproducible one could solve the other issue at the same time ... or not. Hence, I would not bet on different or related right now.

Maybe you could try doing a local svn mirror and then clone from it instead of the remote end to see if it stills fail. A failure with local svn mirror would highly indicate a different issue. Otherwise, they are probably related.

[hkdennis2k]

I am hitting the same crash during git svn fetch. and I've traced and seem to be a issue of _Delta.dll.

Signal SEGV at /mingw64/share/perl5/site_perl/Git/SVN/Fetcher.pm line 368.
        Git::SVN::Fetcher::apply_textdelta(Git::SVN::Fetcher=HASH(0x6019ad6b0), HASH(0x602fd1098), undef, _p_apr_pool_t=SCALAR(0x602fd0fa8)) called at /usr/lib/perl5/vendor_perl/SVN/Ra.pm line 623
        SVN::Ra::Reporter::AUTOLOAD(SVN::Ra::Reporter=ARRAY(0x602310b10), SVN::Pool=REF(0x601a692f8)) called at /mingw64/share/perl5/site_perl/Git/SVN/Ra.pm line 308
        Git::SVN::Ra::gs_do_update(Git::SVN::Ra=HASH(0x6018cf9d0), 2, 4, Git::SVN=HASH(0x601990138), Git::SVN::Fetcher=HASH(0x6019b1298)) called at /mingw64/share/perl5/site_perl/Git/SVN.pm line 1205
        Git::SVN::do_fetch(Git::SVN=HASH(0x601990138), HASH(0x601a65248), 4) called at /mingw64/share/perl5/site_perl/Git/SVN/Ra.pm line 471
        Git::SVN::Ra::gs_fetch_loop_common(Git::SVN::Ra=HASH(0x6018cf9d0), 4, 4, ARRAY(0x601a64f60)) called at /mingw64/share/perl5/site_perl/Git/SVN.pm line 1963
        Git::SVN::fetch(Git::SVN=HASH(0x601990138), 3, 4) called at /mingw64/share/perl5/site_perl/Git/SVN.pm line 1136
        Git::SVN::find_parent_branch(Git::SVN=HASH(0x601998560), HASH(0x6019b4e28), 466) called at /mingw64/share/perl5/site_perl/Git/SVN.pm line 1200
        Git::SVN::do_fetch(Git::SVN=HASH(0x601998560), HASH(0x6019b4e28), 466) called at /mingw64/share/perl5/site_perl/Git/SVN/Ra.pm line 471
        Git::SVN::Ra::gs_fetch_loop_common(Git::SVN::Ra=HASH(0x6018cf9d0), 402, 6997, ARRAY(0x601945150)) called at /mingw64/share/perl5/site_perl/Git/SVN.pm line 1963
        Git::SVN::fetch(Git::SVN=HASH(0x601998560), 0, 6997) called at /mingw64/share/perl5/site_perl/Git/SVN.pm line 1136
        Git::SVN::find_parent_branch(Git::SVN=HASH(0x60194e360), HASH(0x60194df40), 6998) called at /mingw64/share/perl5/site_perl/Git/SVN.pm line 1200
        Git::SVN::do_fetch(Git::SVN=HASH(0x60194e360), HASH(0x60194df40), 6998) called at /mingw64/share/perl5/site_perl/Git/SVN/Ra.pm line 471
        Git::SVN::Ra::gs_fetch_loop_common(Git::SVN::Ra=HASH(0x6018cf9d0), 6997, 106626, ARRAY(0x600debc60), ARRAY(0x600debc78)) called at /mingw64/share/perl5/site_perl/Git/SVN.pm line 179
        Git::SVN::fetch_all("svn", HASH(0x6018cf730)) called at C:\PortableGit-2.5.2.2-64-bit\mingw64/libexec/git-core\git-svn line 570
        main::cmd_fetch() called at C:\PortableGit-2.5.2.2-64-bit\mingw64/libexec/git-core\git-svn line 386

I 'guess' it might be a bug of upstream project, either Perl or SVN.pm

PS. I work on a local SVN mirror for a few months. and having the issues from time to time. Sometime reboot does fix it, some time does not.
I have to skip&ignore those huge tags/brances as a only workaround.

[PZWulff]

Same problem here. :-(
Another workaround is to temporarily "upgrade" to 1.8.5.2, it works perfectly with huge repos, but you might get other issues with ssl ciphers... At least you can do a clone with that version.

[RWander]

The same exception.

[AnthonyMastrean]

I'm also trying to bridge an enormous repository and have a similar error on fetch and clone.

$ git svn clone http://foo/bar
...
      0 [main] perl 20384 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump
fatal: malformed index info 100644 6a541db94

Exception: STATUS_ACCESS_VIOLATION at rip=0048360C10C
rax=0000000602840C28 rbx=000000005219E248 rcx=000000060003ABF0
rdx=0000000000000000 rsi=000000000000F214 rdi=0000000000000004
r8 =0000000000000000 r9 =0000000000000000 r10=0000000000230000
r11=000000048D78607A r12=0000000000000003 r13=000006FFFFE890B8
r14=00000006019AFA40 r15=000006FFFFE890D0
rbp=00000000000790A8 rsp=000000000022B7E0
program=C:\Program Files\Git\usr\bin\perl.exe, pid 20384, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B

Running fetch again results in, seemingly, the same changeset being pulled down and crashing at the same file/index again.

---

Windows 7 Pro SP1, 64-bit
Git for Windows 2.6.2

[dscho]

@AnthonyMastrean if you do not want to investigate the issue and work on a fix (which would admittedly require quite a bit of investment of time and effort on your part), I would suggest to work around the issue by using Vagrant.

[chucklu]

@dscho
$ git svn rebase
1 [main] perl 8496 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump
I can reproduce this problem everytime，

and git svn works perfect in version 1.9.5
I install this setup Git-1.9.5-preview20141217.exe from https://github.com/msysgit/msysgit/releases/tag/Git-1.9.5-preview20141217

I wonder if someone can check the difference between the old version 1.9.5 and current version(after you move from msysgit to here)

It's painful to use the old version for git,just because the git svn can not work properly in new version

[dscho]

I can reproduce this problem everytime

Congratulations! That means you are in a much better position to debug this than I am.

[chucklu]

@dscho I can only debug project created by vs,which used C# .
i found this project has .c and .h
so,c or c++?

[LordOfBytes]

I have the same problem.
Every time I try to clone my svn repository I get the same error, in the same way, at the same point.

I tried to downgrade to Git version 1.9.5 (the version chucklu mention above) and it gets past the "critical" point where the newest version (2.6.3) fail every time.

Like Chucklu I'm also unable to debug this problem....Who can (and will) help us ?

[dscho]

Who can (and will) help us ?

@LordOfBytes first of all, you need to understand that you are asking for a _ton_ of assistance here. I spent easily 50 hours on this ticket, trying to reproduce, trying to debug, attempting to work around it. And since you deem yourself unable to debug this issue yourself, you can imagine that you are asking for expert assistance, too, so do the mental arithmetic.

The really tricky part is that this bug seems to be triggered by a combination of MSys2's heap architecture, Perl's internal memory management and the particulars of _certain_ Subversion repositories. Please note that I knew pretty much nothing about those things before I started working on Git for Windows, and I myself had to pick up the expertise as needed. And so could everybody else.

I fear that this ticket is going nowhere if everybody expects somebody else to do the bidding.

[fizyk20]

I also have the same problem. I would gladly help, but unfortunately it would require skills that I simply don't have. Somebody appears to have figured this out though, since this seems to be related: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=780246 Maybe they will be able to help.

[dscho]

@fizyk20 this bug report talks about Perl 5.20 and libsvn < 1.9. In the meantime we have Perl 5.22 and Subversion 1.9.2...

[fizyk20]

Oops, my bad. So it looks like it's something else... Sorry for introducing more noise, then ;)

[dscho]

@fizyk20 no need to feel sorry. You tried to help, and I appreciate that a lot.

[ghost]

I was having the same problem with 64-bit git for windows, but then I tried Git for Windows 2.7.2 - 32 bit, and the problem does not occur for me.

[allenyllee]

I found a temporary solution in stackoverflow, just typegit svn gc
https://stackoverflow.com/questions/32465621/git-svn-clone-malformed-index-info-error

[Journerist]

neither git svn gc nor 2.7.2 32bit solves the issue for me

[nightman68]

@dscho what git package needs to be build?

C:\git-sdk-64\usr\src\MINGW-packages

or

C:\git-sdk-64\usr\src\MSYS2-packages

I'm able to build the last one but the other build terminates with error regarding doc. in the mingw64 shell?!

[dscho]

@nightman68 To run git svn, you need several MSYS2 components as well as some MINGW components.

Perl and Subversion (including the Perl bindings) would be the MSYS2 packages, mingw-w64-git (plus dependencies) would be the MINGW part.

So if you want to rebuild the part which is most likely responsible for the crash, you will want to rebuild _Delta.dll, which is part of the (MSYS2) subversion package (to find out, I ran find /usr/ -name _Delta.dll to determine the full path of the file and then pacman -Qo /usr/lib/perl5/vendor_perl/auto/SVN/_Delta/_Delta.dll to determine the package owning said file).

[dscho]

@nightman68 any luck so far?

[nightman68]

@dscho no. I tried to build subversion package in a msys shell and it terminates with error. I opened an issue Alexpux/MSYS2-packages#499 but nothing happens so far.

A try to "remove" the ruby binding from build was not successful.

I updates my installation today again and the behavior did not changed.

[dscho]

@nightman68 sorry, I missed Alexpux/MSYS2-packages#499 previously and commented there.

[patsissons]

I ran into this issue today and managed to solve it by running git svn fetch in an admin powershell window. running Git 2.8.1 Windows 10 x64.

I was getting a similar error (Exception: STATUS_ACCESS_VIOLATION at rip=0048360C10C) on an extremely large svn commit (roughly 2500 file changes in a single commit)

[main] perl 26228 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump
fatal: malformed index info 100644 525bb7a

I'm not sure whether the elevated console, the powershell console, or both were the solution (i may be able to find out later today). Hopefully my experience can help any others who land here from google.

[dscho]

@patsissons thank you for this comment!

I'm not sure whether the elevated console, the powershell console, or both were the solution

My guess is that the elevated process is allowed more resources, and that it succeeds for that reason.

[stevendegroote]

I've got the same issue.
Ran as Administrator in powershell, but no solution for me, and execution of git svn fetch stopped at exactly the same point.

Exception: STATUS_ACCESS_VIOLATION at rip=0048360C10C
rax=000000060474CC68 rbx=000000005219E248 rcx=0000000600039860
rdx=0000000000000000 rsi=0000000000015EB0 rdi=0000000000000004
r8 =0000000000000000 r9 =0000000000000000 r10=0000000100000000
r11=000000048D78607A r12=0000000000000003 r13=000006FFFF83F598
r14=00000006013CF320 r15=000006FFFF83F5B0
rbp=00000000000AF588 rsp=00000000FFFFBFA0
program=C:\Program Files\Git\usr\binperl.exe, pid 6756, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
000000AF588 0048360C10C (0000000000B, 000FFA7FF01, 004FF967000, 00600A37C00)
00000000004 000520A2EFC (000520AF1ED, 000FFFFC370, 0018012F7E8, 00000000000)
6FFFF83F5A8 0005209BD56 (004FF967000, 00010004403, 5C766F171377143C, 00600039860)
6FFFF83F5A8 000520D65B6 (00000000000, 0000000000D, 00000000000, 00000000000)
6FFFF83F5A8 0005209BD56 (0060474C6B0, 00600039860, 5C766F171377143C, 00600039860)
6FFFF83F5A8 000520205BC (0049F2383BA, 00000000082, 00000000000, 004AE0DA180)
0048D788438 0048D782C49 (006010FCDE8, 006010EA000, 006010C5C20, 00600E08610)
000FFFFC6E0 0048D783189 (006010EA000, 004B3B04577, 000FFFFC6C8, 000FFFFC6E0)
006010FCDE8 004B3AFA72B (004B3AFD894, 004B3B0452D, 000FFFFC758, 000FFFFC760)
006010FCDE8 004B3AFAA4E (006010C5BA8, 004FF967000, 006010C5CA0, 00000000000)
004FF967000 004B3AF52B7 (5C766F171377143C, 000FFFFC860, 00000000000, 00000000000)
004FF967000 004522E4A79 (0000000000B, 000FFFFFF01, 004FF967000, 00600BA19C0)
00000000003 000520A2EFC (5C766F171377143C, 00000000066, 00600039860, 000FFFFFFFF)
000FFFFCCC0 0005209BD56 (00000000001, 000FFFFC9B0, 000FFFFC848, 00600039860)
000FFFFCCC0 000520283F0 (0018030F9C0, 00180225106, 000FFFFCBD0, 00000000000)
000FFFFCCC0 00100401AAA (000FFFFCBD0, 006000281A0, 00000000030, FF0700010302FF00)
End of stack trace (more stack frames may be present)

I believe that I get this issue on the first commit it fetches, which I believe is the initial one to add my sources to version control, and was therefore a pretty hefty one.

I'm running Win10 64-bit, git version 2.8.1.windows.1, svn, version 1.9.3 (r1718519)

[ByteJuggler]

Running Win 10 64-bit, MINGW64 from Windows git version 2.7.4.windows.1, svn version 1.9.3 (r1718519), perl 5, version 22, subversion 1 (v5.22.1) built for x86_64-msys-thread-multi, tried to clone a SourceForge repo this morning and (again) ran into this problem. (I've previously repeatedly run into this some months ago trying to do a trial/test migrations from our large inhouse SVN server, every time I've run into perl crashing. I then found this thread and eventually parked the whole idea.)

The Sourceforge repo I tried to clone this morning however it isn't exactly large, but no matter what I try it still fails with perl crashing within about 20 seconds. Repeated runs of "git svn fetch" also seems to be an excercise in futility and frustration, I've not managed to get a complete/full working git repo yet like this. (Perhaps I'm too impatient, but by comparison, Subversion itself fetches all the branches, tags and trunk in a minute or 3...):

$ git svn init --stdlayout https://svn.code.sf.net/p/jedicodeformat/code jcf_sf
Initialized empty Git repository in C:/Src/ThirdParty/jcf_sf/.git/
      0 [main] perl 22376 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump
$ cd jcf_sf/
$ git svn fetch
[svn-remote "svn"] unknown
$ cd ..
$ rm -rf jcf_sf
$ git svn init https://svn.code.sf.net/p/jedicodeformat/code/trunk jcf_sf
Initialized empty Git repository in C:/Src/ThirdParty/jcf_sf/.git/
$ cd jcf_sf
$ git svn fetch
      0 [main] perl 22708 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump
$ git svn fetch
      0 [main] perl 19492 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump
$ git svn fetch
     14 [main] perl 22708 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump
$ git svn fetch
      0 [main] perl 5736 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump
$ git svn fetch
      0 [main] perl 13440 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump

What can be done to help fix this as it is super infuriating? (The above should hopefully be quite reproducable given the public accessibility and relatively small size of the target repo?)

I would really like to migrate to using git against our internal SVN server, as well as use it (as above) against some Sourceforge and other SVN projects, but every time I make an attempt to move to git I seem to run into this type of crash.

Edit: I've revisited this issue on home PC and surprisingly this issue didn't exist. Subsequently I then upgraded it (git for Windows), now on git version 2.8.1.windows.1. The issue still appears to not exist. I then went back to my work PC and upgraded it to the same level of git for Windows, but it still crashes trying to clone the above SVN repo.

About the only meaningful difference between the 2 machines as far as this is concerned, is the fact that my home PC is behind a home router (no proxy) while the work on is (obviously) behind an NTLM authenticating proxy.

Might proxies have something to do with this problem? Note: The proxy works fine otherwise, e.g. aside from "git svn" as above. E.g. cloning either an SVN repo with SVN works fine, or cloning a git repo with git works just fine. So there's not an actual problem with the proxy per se, or how I've configured it (as far as I know.)

[blikblum]

Getting the same issue with windows 10, git 2.8.1 64bit, rig with 8GB, core i5 from 3 years ago.

Here are the steps to reproduce:

git svn init --trunk=/trunk http://svn.freepascal.org/svn/fpc fpc-play
git svn fetch --revision=33500:HEAD

Got the error:
0 [main] perl 6132 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump
fatal: malformed index info 100644 395a2d3645765f9e5e2cbeca2faa5

dump:
Exception: STATUS_ACCESS_VIOLATION at rip=0048360C10C
rax=0000000602DEC888 rbx=000000005219E248 rcx=000000060003A6E0
rdx=0000000000000000 rsi=000000000001F148 rdi=0000000000000004
r8 =0000000000000000 r9 =0000000000000000 r10=0000000100000000
r11=000000048D78607A r12=0000000000000003 r13=000006FFFFBF8A58
r14=0000000602546B30 r15=000006FFFFBF8A70
rbp=00000000000F8A48 rsp=00000000FFFFBC60
program=C:\Program Files\Git\usr\binperl.exe, pid 6132, thread main

[ByteJuggler]

Reproduced @blikblum steps on my home rig. (Win 10 x64, git 2.8.1.windows.1):
1 [main] perl 9244 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump
fatal: malformed index info 100644 18284544376a998baec

dump:
Exception: STATUS_ACCESS_VIOLATION at rip=0048360C10C
rax=0000000601E970D0 rbx=000000005219E248 rcx=00000006000399A0
rdx=0000000000000000 rsi=000000000000C552 rdi=0000000000000004
r8 =0000000000000000 r9 =0000000000000000 r10=0000000100000000
r11=000000048D78607A r12=0000000000000003 r13=000006FFFFF42AA8
r14=0000000601701870 r15=000006FFFFF42AC0
rbp=0000000000062A98 rsp=00000000FFFFBC60
program=C:\Program Files\Git\usr\binperl.exe, pid 9244, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B

Edit: By the way, out of curiosity I spun up a Linux (Ubuntu) node in the cloud and repeated the test above, which as expected, succeeded without problem (and it literally only took a few minutes including spinning the node up.) It is perhaps a possible workaround for this problem - e.g. create the git svn checkout on a Linux host and then check out from there using normal git clone.

[dscho]

Getting the same issue with windows 10, git 2.8.1 64bit, rig with 8GB, core i5 from 3 years ago.

Here are the steps to reproduce:

@blikblum

me@work MINGW64 /issue-274 (master)
$ git svn init --trunk=/trunk http://svn.freepascal.org/svn/fpc fpc-play
Initialized empty Git repository in D:/test-git/issue-274/fpc-play/.git/

me@work MINGW64 /issue-274 (master)
$ git svn fetch --revision=33500:HEAD
Migrating from a git-svn v1 layout...
Data from a previous version of git-svn exists, but
        .git/svn
        (required for this version (2.8.1.windows.1) of git-svn) does not exist.
Done migrating from a git-svn v1 layout
[svn-remote "svn"] unknown

[dscho]

And even switching the working directory to fpc-play/:

me@work MINGW64 /issue-274 (master)
$ cd fpc-play/

me@work MINGW64 /issue-274/fpc-play (master)
$ git svn fetch --revision=33500:HEAD
svn-remote.svn: remote ref '/Program Files/git/trunk:refs/remotes/origin/trunk' must start with 'refs/'

[dscho]

(Which is to say that 1. the /trunk should be a trunk _without_ leading slash, and 2. you forgot to specify that you do this in Git CMD. Anybody who wants me to be precise in my work may want to think about extending the same courtesy to me.)

[dscho]

So here is the level of precision I would have expected in the report:

me@work MINGW64 /issue-274/fpc-play (master)
$ git svn fetch --revision=33500:HEAD
        A       utils/fpcmkcfg/fppkg.cfg
        A       utils/fpcmkcfg/default.inc
[6,974 similar lines deleted for readability]
        A       tests/test/cg/obj/linux/mips/ctest.o
        A       tests/test/cg/obj/linux/mips/tcext4.o
      1 [main] perl 7276 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump
fatal: malformed index info 100644

I suspect that it happens at different times always. Would be a vital piece of information.

As it is, I unfortunately spent as much time on this ticket as I can afford for now.

[blikblum]

@dscho
I'm using windows command line (cmd.exe) with git in the PATH

The crashes occurs at different points in the fetch progress, mostly around 5000-5100 files fetched. The total number of files fetched is 16358

The order of file fetched changes at each time the fetch command is run sequentially. In my system, running fetch 3 times the first file was utils/debugsvr/gtk/bitmaps/clear.xpm, utils/ppdep.pp and utils/fppkg/lnet/ltelnet.pp respectively

The "fatal: malformed index info 100644" is printed occasionally

Here are the updated steps (using windows 10, git 2.8.1 64bit, 8GB memory):

git svn init --trunk=trunk http://svn.freepascal.org/svn/fpc fpc-play
cd fpc-play
git svn fetch --revision=33500:HEAD
        A      utils/debugsvr/gtk/bitmaps/clear.xpm
        A      utils/debugsvr/gtk/bitmaps/error.xpm
        [>5000 lines deleted for readability]
        A       packages/fcl-db/src/sqldb/interbase/fbeventmonitor.pp
        A       packages/fcl-db/src/sqldb/examples/database.ini
        A       packages/fcl-db/src/sqldb/examples/dshowtable.pp
0 [main] perl 6300 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump

In the fourth fetch command, ran sequentially after a initial init command, the process was completed successfully

[Jens-G]

I can reproduce the problem too. But interestingly it only happens on 64 bit. Using a 32 bit OS I succeeded. Maybe this information helps to find the issue. I used the curent git for Windows stable builds.

NB: I did not test the combination of running 32 bit git on 64 bit OS. So I can't say anything about this combination.

[tfreier]

Not sure if that helps but I was able to get around this error by using ssh+svn instead of http.

[hkdennis2k]

Recently I realize this problem is nothing about git and why it is hard to reproduce.
The perl will crash when available physical memory is low. (e.g. size of commit larger then available memory)

If anyone still trying to create a mcve, you may want to try in a VM with little ram.

For the others looking for workaround, a PC restart will help :). Also, incremental fetch can prevent internal memory leak and greater successful rate when fetching large repo.

begin=$(git config -f .git/svn/.metadata --get svn-remote.svn.branches-maxrev || echo 1)
git svn fetch -r${begin}:$((begin + 1 ))

[wimh]

I was able to resolve my problem after setting both core.packedGitLimit and core.packedGitWindowSize to 256m:

git svn init svn://192.168.....
git config --local core.packedGitLimit 256m
git config --local core.packedGitWindowSize 256m
git svn fetch 

After this I tested a lot of times and had a crash once, but looks like a different cause.

[dscho]

Finally some high quality analysis: http://article.gmane.org/gmane.comp.version-control.git/298427

[Dirk1966]

The git svn is a known problem on smaller systems. I tried multiple git versions on Ubuntu and Arch LinUX with always bad results on small systems. I can only tell you, that you should use larger Unix systems for larger svn repositories.
I made an analysis here with different compiled git versions in LinUX:
[https://github.com/git-for-windows/git/issues/708#issuecomment-214624478]

[dscho]

@Dirk1966 do you have an way to test a fix on Windows? If so, I just uploaded a tentative 64-bit package to https://github.com/dscho/MSYS2-packages/releases/tag/subversion-1.9.4-2 (and 32-bit is building as we speak). I would be really grateful if you could give it a whirl.

[dscho]

Update: the 32-bit package is now uploaded, too.

[wimh]

@dscho I did not completely follow the instructions, but I did test the patch on windows and I see partial improvements.

Using 32-bit git version 2.9.0.windows.1 on 64-bit windows, I first verified I could still reproduce this issue. I did a git svn init + git svn fetch in an empty directory twice. Both times it crashed.

Then I replaced all msys-svn*.dll files in C:\Program Files (x86)\Git\usr\bin with the version from your package. Using the same test on an unchanged repo I was able to successfully clone it twice!

But I also saw the following errors when starting either svn init or svn fetch:

      0 [main] perl 1948 child_info_fork::abort: address space needed by '_Wc.dll' (0x440000) is already occupied
      0 [main] perl 2112 child_info_fork::abort: address space needed by '_Wc.dll' (0x440000) is already occupied
      0 [main] perl 2236 child_info_fork::abort: address space needed by '_Wc.dll' (0x440000) is already occupied
      1 [main] perl 3044 child_info_fork::abort: address space needed by '_Wc.dll' (0x440000) is already occupied
      0 [main] perl 1728 child_info_fork::abort: address space needed by '_Wc.dll' (0x440000) is already occupied
Can't fork, trying again in 5 seconds at C:\Program Files (x86)\Git\mingw32/libexec/git-core\git-svn line 1960.
      0 [main] perl 356 child_info_fork::abort: address space needed by '_Wc.dll' (0x440000) is already occupied
Can't fork, trying again in 5 seconds at C:\Program Files (x86)\Git\mingw32/libexec/git-core\git-svn line 1960.
      1 [main] perl 3012 child_info_fork::abort: address space needed by '_Wc.dll' (0x440000) is already occupied
Can't fork, trying again in 5 seconds at C:\Program Files (x86)\Git\mingw32/libexec/git-core\git-svn line 1960.
      1 [main] perl 2828 child_info_fork::abort: address space needed by '_Wc.dll' (0x440000) is already occupied
Can't fork, trying again in 5 seconds at C:\Program Files (x86)\Git\mingw32/libexec/git-core\git-svn line 1960.
      1 [main] perl 2224 child_info_fork::abort: address space needed by '_Wc.dll' (0x440000) is already occupied
Can't fork, trying again in 5 seconds at C:\Program Files (x86)\Git\mingw32/libexec/git-core\git-svn line 1960.
      1 [main] perl 2644 child_info_fork::abort: address space needed by '_Wc.dll' (0x440000) is already occupied
.....(keeps repeating)

Finally I still saw a crash during the fetch once.

Note I had tortoisegit also installed. I'll test the 64-bit version without tortoisegit installed.

On 64-bit I tested the same 6 times, after replacing the dll's I had:

• 4 crashes
• 2 were successful
• no address space errors.
  Without the patch, it crashed every time.

Should I test more, or do you want more details?

[uecasm]

The address space issues probably mean that you need to rebase one or more of the DLLs. Fork is really picky about getting DLLs loaded at the same address space as in the parent process (which makes it ASLR incompatible), even when it's about to exec and this is completely unnecessary. I wish more stuff were updated to the spawn APIs instead.

The good news is that address space issues tend to be less of a problem in the 64-bit version.

[dscho]

@wimh I am an idiot. My rebuilt packages did not have the patch applied! Terribly sorry!

I just re-uploaded fixed packages. May I ask you to test again, please?

[dscho]

I wish more stuff were updated to the spawn APIs instead.

This is Open Source, baby! :grinning: You can make your wishes come true.

[wimh]

@dscho No problem. But the new packages do not seem to improve it compared to the previous one.

I tested the 64-bit version 6 times, all of them crashed during the svn fetch.

The 32-bit version has still this address space issue. Of the 6 or 7 times when there was no address space error, 3 were successful, the others crashed. Note I was also able to clone it once successful without the patch applied. So I am not able to reproduce the original issue 100%

md5sums of packages I used for testing today:

31d0e504c68f49b4116f34d7cd19f8ec  subversion-1.9.4-2-i686.pkg.tar.xz
4d515193d459b49e5260eebf60eb7c7f  subversion-1.9.4-2-x86_64.pkg.tar.xz

to be complete, md5sums of yesterday's packages:

95877d5795c107a8453e3ddc4f68901a  subversion-1.9.4-2-i686.pkg.tar.xz
9f4482b582eb9ada17142a89628b8a6f  subversion-1.9.4-2-x86_64.pkg.tar.xz

I will be happy to test more, or collect more details.

[Dirk1966]

@dscho, sorry, the command "git svn fetch --revision=33500:HEAD" does not work in the git4Windows environment. I had only warnings under LinUX, but the last command of the following three does not work there any more:
git svn init --trunk=/trunk http://svn.freepascal.org/svn/fpc fpc-play
cd fpc-play
git svn fetch --revision=33500:HEAD

[dscho]

I tested the 64-bit version 6 times, all of them crashed during the svn fetch.

@wimh bummer! I really hoped that this patch would solve that issue.

[wimh]

@dscho it would be good if someone else subscribed to this thread did some tests too. Maybe I made a mistake, or there might be another problem with the same symptoms. I do have the same error message as posted by others in this thread. Note that I only tested with "git svn fetch --revision 71600:HEAD". Downloading 70000 revisions takes too long. (even though I use a local mirror of svn://svn.reactos.org/reactos/trunk/reactos). Also after I posted, I tested the 64-bit version 3 more times. One of them was successful, so it does not fail every time. The 32-bit address space errors seem to come in batches. For example it comes 10 times in a row, and then 5 times not. Maybe something similar is happening to the 64-bit version. That means testing it 6 times is not enough.

[andrewlancaster]

After so many attempts to solve this issue, running it in Command Prompt as Administrator is what got it to work. Kinda silly!

[rubu]

I don't know if it is of any help, but I stumbled on this issue today while installing a clean development PC and in my case I initially took Git-2.11.0-64-bit.exe which showed all the above symptoms (crashes in perl during svn fetch) but rolling back to Git-2.10.2-64-bit.exe seemed to make the issues go away.

[s-limo]

While this may be not real solution (?), I added some entries to .gitconfig and was able to avoid crash:

[core]
  packedGitLimit = 256m
  packedGitWindowSize = 256m
  longpaths = true
[http]
  postBuffer = 524288000
[pack]
  deltaCacheSize = 256m
  packSizeLimit = 256m
  windowMemory = 1024m

And for some projects I've doubled those limits.

P.S. lowering limits might help to reproduce issue.

[red1939]

Using version 2.12 the problem seem to go away (2.11 is failing though).

[asheiduk]

I tried to import exactly one revision with several thousand files and very long filenames (i.e. core.longPath=true):

git svn init $URL
git svn fetch -r$REV:$REV

Versions up to and including 2.11 crashed in three of four runs - always at different points.
I noticed that the crashes happen even more times when I added --quiet to the fetch step. So this seems to be some kind of a race condition.

The good news: I tried 2.12 and even with --quiet I had zero crashed in five runs. Who deserves the beer?

[chucklu]

@dscho @uecasm @asheiduk
this issue maybe fixed by the commit 80ba04ed9b07c34af9cc644f2183b3b80fd81744
I have tested the version 2.12.0,It's working now.

[asheiduk]

@chucklu @dscho I'm not familiar with the code, but I don't think that 80ba04e solved the problem at hand:

• It handles quoting of refs. My example handles exactly one SVN-Branch and hence one ref in git. The branch name doesn't have any funny characters.
• My example fetches exactly one revision and crashes at wildly different paths at each run. Other comments also report indeterministic behaviour to some degree. I don't understand how 80ba04e can provoke that - it seems completely deterministic to me.

Skimming through v2.11.0..v2.12.0 in the gitster repo I would expect something like abd5a0026868e4c8e59126469dd76fe078689a27 to be the real solution. But don't know whether git-svn calls that piece of code or not.

[dscho]

I'm not familiar with the code, but I don't think that 80ba04e solved the problem at hand

I would agree. For one, the crashes occur in the Subversion module while running the git-svn Perl script.

To me, it looks as if this is an incorrect cast problem (maybe something in the Subversion module is cast from a pointer to an unsigned long, which works fine on Linux because both data types have the same size there, but on 64-bit Windows, an unsigned long is 32-bit while the pointer is 64-bit). This would also explain why the bug is so elusive to reproduce.

[DragosPT]

I had the same problem and the fix was to properly set the proxy settings in C:\Users[user].subversion\servers

[spashx]

Same issue on Windows 2012 R2 64 bits/GIT 2.6.3 64 bits/SVN 1.9.5 64 bits with 4.5GB svn repo.
problem SOLVED with upgrade to GIT 2.13.1

[mkrso]

This issue still exists for me with 2.18.0 64bit

[dscho]

@mkrso if it really still exists, even with the newest pre-release (currently https://github.com/git-for-windows/git/releases/tag/v2.19.0-rc0.windows.2), then please make sure to provide a Minimal, Complete & Verifiable Example.

[josesimoes]

I have version 2.20.1.windows.1 installed and when trying to perform a simple git svn clone (...) it doesn't crash but it just outputs this:

Initialized empty Git repository in E:/temp/xxxxxxx/.git/

and it hangs in there forever. I've tried this a couple of times. The last one left it running for 2 days. I can notice there there a an increase in CPU activity meaning that's doing (trying to) but never ends.

[rimrul]

@josesimoes That sounds more like #1993. You're probably cloning via HTTPS and according to the documentation git svn clone runs git svn init and git svn fetch. That hanging issue should be fixed in the next Git for Windows release.

[dscho]

Can y'all please test with v2.21.0? It should be fixed via #1993.

[breakersun]

still got problem with v2.21.0.

git svn clone https://10.84.130.172/xxxx Initialized empty Git repository in G:/xxx/.git/ 1 [main] perl 2424 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump

perl.exe.stackdump:

Exception: STATUS_ACCESS_VIOLATION at rip=00000000000
rax=0000000000000000 rbx=0000000601130D58 rcx=0000000601139D98
rdx=00000006011420D8 rsi=0000000000000000 rdi=0000000000000011
r8 =0000000000000000 r9 =0000000601177938 r10=0000000100000000
r11=0000000601177938 r12=00000000FFFFC218 r13=0000000601130DE8
r14=0000000601139D98 r15=0000000000000000
rbp=00000000FFFFC210 rsp=00000000FFFFC1A8
program=D:\Program Files\Git\usr\binperl.exe, pid 2424, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
End of stack trace

[dscho]

still got problem with v2.21.0.

Bummer.

@breakersun please understand that these issues are extremely involved to investigate. So much so that I, for example, cannot afford to invest the time.

Hopefully you can, or maybe you know somebody competent enough who can, an are able to bribe them into doing it.

[breakersun]

still got problem with v2.21.0.

Initialized empty Git repository in G:/xxx/.git/
      1 [main] perl 2424 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump```


perl.exe.stackdump:

Exception: STATUS_ACCESS_VIOLATION at rip=00000000000
rax=0000000000000000 rbx=0000000601130D58 rcx=0000000601139D98
rdx=00000006011420D8 rsi=0000000000000000 rdi=0000000000000011
r8 =0000000000000000 r9 =0000000601177938 r10=0000000100000000
r11=0000000601177938 r12=00000000FFFFC218 r13=0000000601130DE8
r14=0000000601139D98 r15=0000000000000000
rbp=00000000FFFFC210 rsp=00000000FFFFC1A8
program=D:\Program Files\Git\usr\bin\perl.exe, pid 2424, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame        Function    Args
End of stack trace

I figured it out and find a work around for my issue.
The reason is that SVN repo must be accessed via a http/https proxy.
for git-svn for windows, you must add proxy information in $home/.subversion/servers.(c:\UsersASUS\.subversion\servers), find global sector and uncommet http-proxy-host and http-proxy-host.
on windows, git-svn proxy settings is not same as git proxy settings, that's my problem.

[dscho]

@breakersun whoa. Good analysis! But the absence of a proxy should not let git svn crash...

Is there any chance that you can debug this, say, by rebuilding the subversion package, patching in debug print statements?

[breakersun]

@dscho Thank you. I'd like to help. But I need to do some study first cause this is not my expertise.

[frankggyy]

still got problem with v2.21.0.
Initialized empty Git repository in G:/xxx/.git/
1 [main] perl 2424 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump```

perl.exe.stackdump:

Exception: STATUS_ACCESS_VIOLATION at rip=00000000000
rax=0000000000000000 rbx=0000000601130D58 rcx=0000000601139D98
rdx=00000006011420D8 rsi=0000000000000000 rdi=0000000000000011
r8 =0000000000000000 r9 =0000000601177938 r10=0000000100000000
r11=0000000601177938 r12=00000000FFFFC218 r13=0000000601130DE8
r14=0000000601139D98 r15=0000000000000000
rbp=00000000FFFFC210 rsp=00000000FFFFC1A8
program=D:\Program Files\Git\usr\binperl.exe, pid 2424, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
End of stack trace

I figured it out and find a work around for my issue.
The reason is that SVN repo must be accessed via a http/https proxy.
for git-svn for windows, you must add proxy information in $home/.subversion/servers.(c:\UsersASUS.subversion\servers), find global sector and uncommet http-proxy-host and http-proxy-host.
on windows, git-svn proxy settings is not same as git proxy settings, that's my problem.

Fixed in my environment.

[vitaliyg2]

Same error when try to clone SVN repo over TCP tunnel.
I can access repo using browser and was able to clone it using the SVN client (so this is not a network error), but can't clone because of this error.
This is relatively small repo.
Subsequent git svn fetch results in the same error.

git version 2.22.0.windows.1

0 [main] perl 471 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump

Exception: STATUS_ACCESS_VIOLATION at rip=00000000000
rax=0000000000000000 rbx=0000000601136838 rcx=000000060113F878
rdx=0000000601147BB8 rsi=0000000000000000 rdi=0000000000000011
r8 =0000000000000000 r9 =000000060117D368 r10=0000000100000000
r11=000000060117D368 r12=00000000FFFFC248 r13=00000006011368C8
r14=000000060113F878 r15=0000000000000000
rbp=00000000FFFFC240 rsp=00000000FFFFC1D8
program=D:\Programs\Git\usr\binperl.exe, pid 1680, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame Function Args
End of stack trace

[fuzhibo]

Same error when try to clone SVN repo over TCP tunnel, then I use following config:

[core]
       repositoryformatversion = 0
       filemode = false
       bare = false
       logallrefupdates = true
       ignorecase = true
       longpaths = true
       packedGitLimit = 256m
       packedGitWindowsSize = 256m
[http]
       postBuffer = 534288000
[pack]
       deltaCacheSize = 256m
       packSizeLimit = 256m
       windowMemory = 1024m

It worked, but failure with command git svn rebase. The git version is git version 2.26.0.windows.1. Error report is:

Exception: STATUS_ACCESS_VIOLATION at rip=00000000000
rax=0000000000000000 rbx=0000000000000011 rcx=00000006011337F8
rdx=000000060113B838 rsi=00000000FFFFC260 rdi=00000000FFFFC268
r8 =0000000000000000 r9 =000000060113DBB8 r10=00000006011337F8
r11=000000060113DBB8 r12=000000060112A7B8 r13=00000000FFFFC278
r14=00000000FFFFC270 r15=0000000000000000
rbp=000000060112A848 rsp=00000000FFFFC208
program=C:\Program Files\Git\usr\bin\perl.exe, pid 50, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame        Function    Args
End of stack trace

[dscho]

@fuzhibo does it work for you if you use Git in WSL?

[fuzhibo]

@fuzhibo does it work for you if you use Git in WSL?

It seems worked on WSL. However I use command git svn clone --username=xxx -r xxx:HEAD --trunk=xxx <svn url>. @dscho

[carlbjor]

Adding svn proxy settings helped in my case, as @breakersun suggested in a previous comment

https-proxy-host=
http-proxy-port=