Perl crash during svn clone #274
Comments
|
This is not windows specific. Even under linux if the repository is large enough, git-svn will fail. try calling successive |
|
A few other things that are possibly of interest:
|
That large commit is most probably the cause. The change set is so big that the data |
|
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. 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. |
|
Sorry, without any way to reproduce here, there is nothing I can do. |
|
According to a debugger, the crashing IP is at: And now I've completely run out of ideas of ways to help track this down. |
|
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. |
And didn't you intend to use the 64-bit version of Git for Windows? |
|
Do you have files like |
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.)
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. |
|
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? Still on Git-2.4.6-5th-release-candidate-32-bit (not that it seems to make much difference).
|
As pointed out by @nalla, it is safe to fetch after an access violation. |
|
Still no way to reproduce, eh? |
|
@dscho Facing a similar issue today trying to Got Now, I'm stuck at revision Tried to reproduce with: 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:
|
|
@dscho My last reply was a reproduction recipe. I'm not sure what more you want. |
@uecasm Well, it is kind of a reproduction recipe. The first time I ran it, it crashed after 2m31s, just after adding 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. |
|
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 Here (hopefully) reproducible steps (full steps with own svn to git clone in postscript-um at the end of post): 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 |
|
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. |
|
Sometimes it's an access violation, other times it's a simpler error message. So, it's both :) As I already said, it 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. |
|
I am hitting the same crash during git svn fetch. and I've traced and seem to be a issue of _Delta.dll. 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. |
|
Same problem here. :-( |
|
The same exception. |
|
I'm also trying to bridge an enormous repository and have a similar error on fetch and clone. 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 |
|
@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. |
|
@dscho and git svn works perfect in version 1.9.5 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 |
Congratulations! That means you are in a much better position to debug this than I am. |
|
@dscho I can only debug project created by vs,which used C# . |
|
I have the same problem. 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 ? |
|
After so many attempts to solve this issue, running it in Command Prompt as Administrator is what got it to work. Kinda silly! |
|
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. |
|
While this may be not real solution (?), I added some entries to .gitconfig and was able to avoid crash: And for some projects I've doubled those limits. P.S. lowering limits might help to reproduce issue. |
|
Using version 2.12 the problem seem to go away (2.11 is failing though). |
|
I tried to import exactly one revision with several thousand files and very long filenames (i.e. Versions up to and including 2.11 crashed in three of four runs - always at different points. The good news: I tried 2.12 and even with |
* 'svn-escape-backslash' of git://bogomips.org/git-svn: git-svn: escape backslashes in refnames
|
@chucklu @dscho I'm not familiar with the code, but I don't think that 80ba04e solved the problem at hand:
Skimming through v2.11.0..v2.12.0 in the gitster repo I would expect something like abd5a00 to be the real solution. But don't know whether git-svn calls that piece of code or not. |
I would agree. For one, the crashes occur in the Subversion module while running the 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 |
|
I had the same problem and the fix was to properly set the proxy settings in C:\Users[user].subversion\servers |
|
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. |
|
This issue still exists for me with 2.18.0 64bit |
|
@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. |
|
I have version 2.20.1.windows.1 installed and when trying to perform a simple 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. |
|
@josesimoes That sounds more like #1993. You're probably cloning via HTTPS and according to the documentation |
|
Can y'all please test with v2.21.0? It should be fixed via #1993. |
|
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. |
I figured it out and find a work around for my issue. |
|
@breakersun whoa. Good analysis! But the absence of a proxy should not let Is there any chance that you can debug this, say, by rebuilding the |
|
@dscho Thank you. I'd like to help. But I need to do some study first cause this is not my expertise. |
Fixed in my environment. |
|
Same error when try to clone SVN repo over TCP tunnel. 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 |
|
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 = 1024mIt worked, but failure with command 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 |
|
@fuzhibo does it work for you if you use Git in WSL? |
|
Adding svn proxy settings helped in my case, as @breakersun suggested in a previous comment |
|
Working on bugs in I will therefore simply close this ticket. |
and others
While trying to
git svn clonea 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:The dumpfile contains the following:
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.
The text was updated successfully, but these errors were encountered: