Re: git-send-pack segfaulting on DebianPPC (was: Re: cg-clone, tag objects and cg-push/git-push don't play nice)
- From
Linus Torvalds <torvalds@osdl.org>
- Date
- Oct 19, 2005, 21:09 UTC
- Message-ID
- <Pine.LNX.4.64.0510191405020.3369@g5.osdl.org>
- In-Reply-To
- <46a038f90510191356w56b78413p6b9fe5b67fc9ee74@mail.gmail.com>
On Thu, 20 Oct 2005, Martin Langhoff wrote:
> > On this broken-ish repo, git-fetch-pack segfaults as I've reported. > Running it under strace shows that it dies walking the local repo, > trying to find a missing commit. Unlikely that this is PPC only ;-)
Ok, that's not horribly surprising, but it's wrong.
Since I'm a lazy bastard, and couldn't necessarily re-create the right kind of broken repository even if I weren't, could you just enable core-dumps, and run gdb on the thing and report what "where" says is the call-chain.
It's almost certainly something that looks up an object and dereferences it without checking whether the object lookup succeeded or not. But if you can say where the SIGSEGV happens, it will be easier to figure out where.
Of course, what I really _should_ do is improve "sparse" to the point where I can mark functions as returning "unsafe" pointers, and then have sparse statically find all the dangerous users. I should do that anyway, since it would be useful for the kernel too, but it's actually quite nontrivial.
Linus "being lazy is not a state of mind - it's a way of life" Torvalds