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