Steven Grimm <koreth@xxxxxxxxxxxxx> wrote: > I expect this is really a libsvn bug, but git-svn triggers it, so I'm > hoping someone else has run into and solved it, or at least that someone > can reproduce it. I've also been working with another user off-list the past few days on tracking down on a segmentation fault in git-svn. > If I try to clone the "memcached" public repository with the command line > > git-svn clone --branches=branches --trunk=trunk > http://code.sixapart.com/svn/memcached I just ran this several (6?) times got a segmentation fault once with Junio's master @ f948792990f82a35bf0c98510e7511ef8acb9cd3. Trying it again with the same file that segfaulted earlier, it was successful, spooky... I also tried some other patches (see replies) which I've been testing to fix the other user's problem. > it cranks along fine until revision 299, then dies with SIGSEGV. If I > run it again, it appears to pick up where it left off, then dies again > at revision 399, then again at revision 499. (There are fewer than 600 > revisions in that repo so it's anyone's guess if it'd die at 599 given > the chance.) I have definitely not seen this pattern before. However, the following clone has been problematic at times git svn clone svn://svn.debian.org/svn/pkg-glibc/glibc-package \ -T trunk -b branches -t tags > This happens on both a Linux box (amd64, FC4, svn version 1.4.3) and my > Mac (Intel OS 10.4, svn version 1.2.3 from Fink), so at the very least > it's not platform-specific. It also happens periodically on the private > svn repository at my company, though not as predictably. On my Mac, I'm > using the very latest git code from "master". I'm running x86, Debian Etch, SVN 1.4.2 from Debian Etch or 1.4.3 from Debian experimental + do_switch patch[1] Thanks for the stack trace. This is segfaulting at a different place (expected, being an http:// repo while the other is svn://) [1] - http://svn.haxx.se/dev/archive-2007-01/0936.shtml -- Eric Wong - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html