On Wed, 14 Feb 2007, Bill Lear wrote:
quoted text
> 
> No NFS, but I checked /var/log/messages.  I see segfaults from git,
> that I missed somehow (don't remember seeing anything awry on the
> terminal):
> 
> Feb 14 10:05:07 lisa kernel: git[21648]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4
> Feb 14 10:05:43 lisa kernel: git[21710]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4
> Feb 14 10:06:28 lisa kernel: git[21858]: segfault at 0000000000000000 rip 0000003f5eb709d0 rsp 0000007fbfffc158 error 4
>
> 10:05 is just before I posted my first note of this to the git list, and
> the first instance of a segfault that I see.

Ok, this is almost certainly what's up. For some strange reason your git 
binary segfaults on the clone. The scary thing is, it left your cloned 
repo in a bad state without even telling you. That's not good.  Normally 
we should always die() and give a _reason_ for a failure.

If you have that particular git binary, doing a

	gdb git

and then at the gdb prompt doing

	x/5i 0x0000003f5eb709d0

will at least tell where the SIGSEGV happened, but it doesn't give a 
backtrace so unless it's obvious, it can be a bit hard to debug remotely..

			Linus
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html