Re: git fsck segmentation fault

From: Martin Koegler <mkoegler@auto.tuwien.ac.at>
Date: Dec 9, 2008, 21:57 UTC
Message-ID: <20081209215722.GA8877@auto.tuwien.ac.at>
In-Reply-To: <alpine.LFD.2.00.0812091408560.14328@xanadu.home>

On Tue, Dec 09, 2008 at 02:09:58PM -0500, Nicolas Pitre wrote:

> Has this been looked at?  Martin?

I have not noticed this message.

Show 40 quoted lines

> #54 0x0000000000493c6d in parse_tree (item=0x20d0178) at tree.c:224
> #55 0x0000000000424ca2 in mark_object (obj=0x20d0178, type=2, data=<value 
> optimized out>) at builtin-fsck.c:102
> #56 0x0000000000468d1c in fsck_walk (obj=<value optimized out>, walk=0x424af0 
> <mark_object>, data=0x20d0128) at fsck.c:26
> #57 0x0000000000424cba in mark_object (obj=0x20d0128, type=2, data=<value 
> optimized out>) at builtin-fsck.c:105
> #58 0x0000000000468d1c in fsck_walk (obj=<value optimized out>, walk=0x424af0 
> <mark_object>, data=0x1edb448) at fsck.c:26
> #59 0x0000000000424cba in mark_object (obj=0x1edb448, type=2, data=<value 
> optimized out>) at builtin-fsck.c:105
> #60 0x0000000000468d1c in fsck_walk (obj=<value optimized out>, walk=0x424af0 
> <mark_object>, data=0x1edb420) at fsck.c:26
> #61 0x0000000000424cba in mark_object (obj=0x1edb420, type=2, data=<value 
> optimized out>) at builtin-fsck.c:105
> #62 0x0000000000468bf9 in fsck_walk (obj=0x241a750, walk=0x424af0 
> <mark_object>, data=0x241a750) at fsck.c:50
> #63 0x0000000000424b7d in mark_object (obj=0x241a750, type=1, data=<value 
> optimized out>) at builtin-fsck.c:105
> #64 0x0000000000468c31 in fsck_walk (obj=<value optimized out>, walk=0x424af0 
> <mark_object>, data=0x241a708) at fsck.c:57
> #65 0x0000000000424b7d in mark_object (obj=0x241a708, type=1, data=<value 
> optimized out>) at builtin-fsck.c:105
> #66 0x0000000000468c31 in fsck_walk (obj=<value optimized out>, walk=0x424af0 
> <mark_object>, data=0x4dea0b0) at fsck.c:57
> #67 0x0000000000424b7d in mark_object (obj=0x4dea0b0, type=1, data=<value 
> optimized out>) at builtin-fsck.c:105
> #68 0x0000000000468c31 in fsck_walk (obj=<value optimized out>, walk=0x424af0 
> <mark_object>, data=0x488ff78) at fsck.c:57
> #69 0x0000000000424b7d in mark_object (obj=0x488ff78, type=1, data=<value 
> optimized out>) at builtin-fsck.c:105
> #70 0x0000000000468c31 in fsck_walk (obj=<value optimized out>, walk=0x424af0 
> <mark_object>, data=0x488bd18) at fsck.c:57
> #71 0x0000000000424b7d in mark_object (obj=0x488bd18, type=1, data=<value 
> optimized out>) at builtin-fsck.c:105
> #72 0x0000000000468c31 in fsck_walk (obj=<value optimized out>, walk=0x424af0 
> <mark_object>, data=0x313c0b0) at fsck.c:57
> #73 0x0000000000424b7d in mark_object (obj=0x313c0b0, type=1, data=<value 
> optimized out>) at builtin-fsck.c:105
> [recursion between line 105 and 57]

If I look at the backtrace, nothing seems wrong. The obj pointers for mark_object are all different, so its not stuck in a loop. If you look at type, you will see that it traverses commits (type=1) untils #63. Then it traverses trees (type=2).

At my option, there is a commit with a very long ancestory (~40.000 [stack frame count/2]). As we do depth first search for the reachability check, we need about 80.000 frames.

I suggest, that you retry with a very much bigger stack (ulimit -s).

mfg Martin Kögler