Aelphaeis
Aelphaeis

Reputation: 2613

git svn clone malformed index info error

When I run git svn clone I get the following error :

  0 [main] perl 24432 cygwin_exception::open_stackdumpfile: Dumping stack trace to perl.exe.stackdump
  fatal: malformed index info 100644 362f1c18ceed5d593eb021432545685283a93 

When I open the file I see the following :

Exception: STATUS_ACCESS_VIOLATION at rip=0048360C537 rax=00000006039F81E0 rbx=000000005219E248 rcx=000000060003A3C0 rdx=0000000000000000 rsi=000000000000FDB4 rdi=0000000000000004 r8 =0000000000000000 r9 =0000000000000000 r10=0000000000230000 r11=000000048D785FBA r12=0000000000000003 r13=000006FFFF7FEDB8 r14=00000006014D4030 r15=000006FFFF7FEDD0 rbp=000000000007EDA8 rsp=000000000022BE80 program=C:\Program Files\Git\usr\bin\perl.exe, pid 24432, thread main cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B

I checked the following links :

Error with Git SVN clone

Problem cloning a single SVN Branch via git svn

Python SVN bindings for Windows

subversion python bindings documentation?

Unfortunately, I'm not familiar enough for the underlying technologies to figure out exactly what I should be doing. Would could be causing this and how might I be able to resolve?

Upvotes: 43

Views: 19961

Answers (16)

image357
image357

Reputation: 471

For me the proxy settings fixed it. See also: https://github.com/git-for-windows/git/issues/274#issuecomment-473826553

Inside C:\Users\USERNAME\.subversion\servers set

[global]
http-proxy-host = [insert IP here]
http-proxy-port = [insert port here]

Upvotes: 0

w0q
w0q

Reputation: 1

if SVN repo must be accessed via a http/https proxy need config proxy in file

c:\Users\...\.subversion\servers.

In [global] section set http-proxy-host and http-proxy-port.

Solution from

https://github.com/git-for-windows/git/issues/274#issuecomment-473826553

Upvotes: 0

Nabil
Nabil

Reputation: 121

Executing rebase.exe in C:\Program Files\Git\usr\bin solved it for me. I found the solution in here https://github.com/msysgit/msysgit/issues/25

Upvotes: 0

VinceStyling
VinceStyling

Reputation: 3827

in my case, this error happened at Ubuntu 16.04 and the version is git-svn version 2.17.0 (svn 1.9.3) after I ran git svn --version command, i switch to my MacOS which version info is git-svn version 2.17.0 (svn 1.7.20) after I ran git svn --version command, then switch back to ubuntu after succeeded clone & fetch and other operations in MacOS.

Upvotes: 0

Dominik Jeník
Dominik Jeník

Reputation: 25

I can reproduce this problem every time,and git svn works perfect in

version 1.9.5

You can install it from 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.

Upvotes: 0

matthias.lukaszek
matthias.lukaszek

Reputation: 2220

Update: After updating to Ubuntu 17.04 with 2.11.0 and git-svn 1:2.11.0-2ubuntu0.2 the clone worked flawlessly.

I found a funny solution for that issue while debugging through the perl scripts:

  • Slow down or somehow manipulate the execution by running git svn in the perl debugger.

Start git svn fetch with the following command (you might have to change the paths. This should also work with clone). Make sure to run the command inside your git repository / directory:

perl -d /usr/lib/git-core/git-svn fetch

Enter the following into the debugger and press ENTER:

b /usr/share/perl5/Git/SVN/Fetcher.pm:368 $base==undef or $dup==undef

This basically adds a conditional breakpoint at the position where I get the signal 11. This is the line of code:

[ SVN::TxDelta::apply($base, $dup, undef, $fb->{path}, $fb->{pool}) ];

Then enter c to continue the execution and press ENTER.

Can someone explain why this helps?

Edit: It worked: 213000 revisions and 1780 branches cloned into git!

Upvotes: 16

lcltj
lcltj

Reputation: 1598

Here is the problem I have:

  • OS: xubuntu 16.04
  • git-svn version 2.7.4 (svn 1.9.3)

Trace info from perl -d /usr/lib/git-core/git-svn fetch:

Signal SEGV at /usr/local/share/perl/5.22.1/Git/SVN/Fetcher.pm line 368
    Git::SVN::Fetcher::apply_textdelta(Git::SVN::Fetcher=HASH(0x20ee160), HASH(0x2488a40), undef, _p_apr_pool_t=SCALAR(0x2488bf0)) called at /usr/lib/x86_64-linux-gnu/perl5/5.22/SVN/Ra.pm line 623
    SVN::Ra::Reporter::AUTOLOAD(SVN::Ra::Reporter=ARRAY(0x8d0fa0), SVN::Pool=REF(0x20ee910)) called at /usr/local/share/perl/5.22.1/Git/SVN/Ra.pm line 308
    Git::SVN::Ra::gs_do_update(Git::SVN::Ra=HASH(0x20df170), 42560, 42560, Git::SVN=HASH(0x20dea08), Git::SVN::Fetcher=HASH(0x20ee160)) called at /usr/local/share/perl/5.22.1/Git/SVN.pm line 1205
    Git::SVN::do_fetch(Git::SVN=HASH(0x20dea08), HASH(0x20ee1d8), 42560) called at /usr/local/share/perl/5.22.1/Git/SVN/Ra.pm line 471
    Git::SVN::Ra::gs_fetch_loop_common(Git::SVN::Ra=HASH(0x20df170), 42500, 95400, ARRAY(0x1637c08), ARRAY(0x1637c20)) called at /usr/local/share/perl/5.22.1/Git/SVN.pm line 179
    Git::SVN::fetch_all("svn", HASH(0x20dee28)) called at /usr/lib/git-core/git-svn line 570
    main::cmd_fetch() called at /usr/lib/git-core/git-svn line 386
    eval {...} called at /usr/lib/git-core/git-svn line 384
Aborted (core dumped)

I finally fixed this problem by the following steps(This is for Ubuntu Linux 16.04 users):

sudo apt build-dep subversion
sudo apt install libneon27-dev
sudo cpan SVN::Core

Then I can use git svn fetch/clone without any crash.

The root cause of this problem is that the Perl SVN::Core library script does not match the binaries installed in Perl(There are separate subversion binaries installed in Perl beside the system installed ones).

Beware this will downgrade your git-svn's svn version to 1.8.11(before it's 1.9.3), and might cause other problems.

Upvotes: 2

feos
feos

Reputation: 1116

I was getting all sorts of errors with git-svn where the perl script would die in various places, fetching would break, or the server would cut the connection. This was a huge repo that took dozens GBs when checked out via svn.

What solved this for me was simply using SmartGit instead of git-svn. It required Java 8, ran extremely fast, and reported no errors whatsoever, seamlessly completing in a few hours the task that took svn several days.

Upvotes: 2

h3n
h3n

Reputation: 5248

In my case, I was not connected to our VPN, which is needed for our svn connection. This is my error:

Exception: STATUS_ACCESS_VIOLATION at rip=00000000000
rax=0000000000000000 rbx=00000006010BBDA8 rcx=00000006010BBDA8
rdx=00000006010C40E8 rsi=0000000000000011 rdi=0000000000000000
r8 =0000000000000000 r9 =00000006010EBCA8 r10=0000000100000000
r11=000000049F2423C9 r12=00000000FFFFC190 r13=00000000FFFFC198
r14=00000006010B2DF8 r15=00000006010B2D68
rbp=00000000FFFFC1A8 rsp=00000000FFFFC138
program=C:\Program Files\Git\usr\bin\perl.exe, pid 7884, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B
Stack trace:
Frame        Function    Args
End of stack trace

Upvotes: 2

Marc W.
Marc W.

Reputation: 63

For me the only solution that worked was using an older version of Git. I used the portable package of Git 1.8.3 which can be downloaded here:

https://github.com/msysgit/msysgit/releases/tag/Git-1.8.3-preview20130601

with it there was no need for .git/config edits, splitted checkouts, or perl debug statements.

Upvotes: 2

P.D.P.
P.D.P.

Reputation: 637

Check which svn commit caused the problem.

The commits are outputted by the git svn clone command, preceded by an r. The last commit that is outputted is the problematic one.

The next example shows what the git svn clone command outputs when begin procesing the Subversion revision 15 as the Git commit 373fb1...:

r15 = 373fb1de430a6b1e89585425f276aae0058c3deb (refs/remotes/svn/trunk)

Split up the git svn clone command using the -r (revision) option

Use this method:

git svn clone -r 0:<problematic_revision - 1> <repo URL>
git svn clone -r <problematic_revision - 1>:problematic_revision <repo URL>
git svn clone -r <problematic_revision>:HEAD <repo URL>

Supposing the revision 15 as the problematic one, and the repo in /tmp/svn/repo/, the solution would be:

git svn clone -r  0:14   file:///tmp/svn/repo/
git svn clone -r 14:15   file:///tmp/svn/repo/
git svn clone -r 15:HEAD file:///tmp/svn/repo/

Upvotes: 4

Rajat Srivastava
Rajat Srivastava

Reputation: 279

I got this error while migrating huge svn repository to git using svn2git tool. I added below lines in my .git/config file and it started working:

[core]
    repositoryformatversion = 0
    filemode = false
    bare = false
    logallrefupdates = true
    symlinks = false
    ignorecase = true
    hideDotFiles = dotGitOnly
    packedGitLimit = 256m
    packedGitWindowSize = 256m
    longpaths = true
[http]
    postBuffer = 524288000
[pack]
  deltaCacheSize = 256m
  packSizeLimit = 256m
  windowMemory = 1024m

These settings are explained at the git-config man page.

Upvotes: 21

sevensevens
sevensevens

Reputation: 1750

I was able to check out the svn repo correctly using Cygwin.

Upvotes: 1

meow
meow

Reputation: 307

Updated - The problem still occurs after git gc for me. I tried every version of git windows (both 32 and 64 bit), but still I got this error. Then I switched to using git on linux and it works fine for me, even for extremely large commits. I recommend to switch to linux otherwise you are out of luck as the issue raised here - https://github.com/git-for-windows/git/issues/274 is almost 6 months old.

Updated - To add to centic's answer, the git gc only works fine for 32-bit git for windows, for this particular problem.

I think the problem exists for 64-bit git for windows. I was having the same problem with 64 bit git, but after switching to git 2.7.2 windows 32-bit, the problems seems to be solved for me.

Upvotes: 3

syned
syned

Reputation: 2321

In my case this error happened with big repository. So try to clone subfolder if possible.

Upvotes: 0

centic
centic

Reputation: 15882

I had similar exceptions and error messages, for me a

git gc

and/or a

git svn gc

brought the repository back into a usable state. See also https://stackoverflow.com/a/1436386/411846

Upvotes: 6

Related Questions