Re: epic fsck SIGSEGV! (was Recovering from epic fail (deleted .git/objects/pack))

From: Linus Torvalds <torvalds@linux-foundation.org>
Date: Dec 11, 2008, 00:45 UTC
Message-ID: <alpine.LFD.2.00.0812101636351.3340@localhost.localdomain>
In-Reply-To: <1228955062.27061.36.camel@starfruit.local>

On Wed, 10 Dec 2008, R. Tyler Ballance wrote:

Show 7 quoted lines

>
> The stack size is 8M as you assumed, I'm curious as to how the kernel
> handles a process that exceeds the ulimit(2) stacksize. I know from our
> experience with this repository that when Git runs up against the
> address space (ulimit -v) that an ENOMEM or something similar is
> returned. Is there an E_NOSTACK? :) (figured I'd ask, given your
> apparent knowledge on the subject ;))

Since stack expansion doesn't involve any system calls, and since there is no way to recover from it anyway, the kernel has no choice: it just sends a SIGSEGV.

An application that wants to _can_ handle this case by installing a signal handler, but since signal handling needs some stack-space too, a regular "sigaction(SIGSEGV..)" isn't sufficient. You also need to set up a separate signal stack ..

Nobody really ever does that, except for some _really_ special programs. But it's a way to handle errors in stack allocation if you really need to. Git certainly does not do it.

Show 6 quoted lines

> > (You can do something like
> > 
> > 	git rev-list --first-parent HEAD | wc -l
> 
> tyler@ccnet:~/source/slide/brian_main>  git rev-list --first-parent HEAD | wc -l
> 46751

Ahh. yes. The 80k number is because the callchain was that deep, but since each recursion involves _two_ functions, it really only needed a 40k commit depth to the root to get there.

Show 10 quoted lines

> > But we should definitely fix this braindamage in fsck. Rather than 
> > recursively walk the commits, we should add them to a commit list and just 
> > walk the list iteratively.
> 
> Given that this issue affects our internal (proprietary) repository, I
> can't very well give access to it or publish a clone, but I'm willing to
> help in any way I can. We maintain an internal fork of the Git tree, so
> I can apply any changes you'd like to an internal 1.6.0.4 or 1.6.0.5
> build. For obvious reasons I ran the fsck against an upstream maintained
> (stable) build of Git.

Can you try with a bigger stack? Just do

	ulimit -s 16384

and then re-try the fsck. Just to verify that this is it. If nothing else, it will at least give you a working fsck, even if it's obviously not the "correct" solution.

		Linus