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

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.

quoted

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

quoted

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