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

[Linus Torvalds <torvalds@linux-foundation.org>]

On Wed, 10 Dec 2008, R. Tyler Ballance wrote:
>
> 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.

> > (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.

> > 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