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