{"thread":{"id":"16502","subject":"git fsck segmentation fault","startedAt":"2008-11-27T17:14:06Z","lastAt":"2008-12-11T06:42:40Z","messageCount":12,"participants":["Simon Hausmann","Nicolas Pitre","Martin Koegler","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"96627","messageId":"200811271814.06941.simon@lst.de","threadId":"16502","inReplyTo":null,"subject":"git fsck segmentation fault","fromName":"Simon Hausmann","fromEmail":"simon@lst.de","sentAt":"2008-11-27T17:14:06Z","receivedAt":"2008-11-27T17:14:06Z","isPatch":false,"sender":{"key":"hausmann@kde.org","avatar":"https://gravatar.com/avatar/bc9aad4fb31dce17eb66e690e7b51fe980c62da3c225c785da35dd806b8da778?d=mp&s=160"},"body":"Hi,\n\nwhen running git fsck --full -v (version 1.6.0.4.26.g7c30c) on a medium sized\n(930M) repository I get a segfault.\n\nThe backtrace indicates an infinite recursion. Here's the output from the last\nfew lines:\n\nChecking commit ffffb0556074699814751f3b34526b3d6850c6f7\nChecking blob ffffb4e9edf03e7f5643abc5603ca57e745c313d\nChecking tree ffffde1114cdd0937cb798069b45f4ceadccd22f\nChecking tree ffffe7e34be267ca55a6ae823f8bf31d7a8ef3cd\nChecking blob ffffe8bbfc4d7adcb4e5fa00f1b4c99e26591b76\nChecking tree ffffea81b8790b194ac215807165e3ff7f824320\nChecking blob ffffec79ba618a429dee33bb0acb0ab36cb1310d\nChecking tree fffff62eaba873e3ea3cfd7535e6ac514fd18332\nChecking blob fffff6519569fac30b11b7bc830d61e296b7c5e2\nSegmentation fault (core dumped)\n\ngdb on the core file produces the following backtrace:\n\n#0 0x0000000000487684 in unpack_object_header (p=0x26ad4c0, w_curs=0x7fff72f8a060, curpos=0x7fff72f8a058, sizep=0x7fff72f8a0c8) at sha1_file.c:1400\n1400 base = use_pack(p, w_curs, *curpos, &left);\n\n\n#0 0x0000000000487684 in unpack_object_header (p=0x26ad4c0, w_curs=0x7fff72f8a060, curpos=0x7fff72f8a058, sizep=0x7fff72f8a0c8) at sha1_file.c:1400\n#1 0x000000000048827e in unpack_entry (p=0x26ad4c0, obj_offset=490508859, type=0x7fff72f8cd14, sizep=0x7fff72f8a004) at sha1_file.c:1693\n#2 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=490581247, type=0x7fff72f8cd14, sizep=0x7fff72f8a148) at sha1_file.c:1647\n#3 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=490679881, type=0x7fff72f8cd14, sizep=0x7fff72f8a1c8) at sha1_file.c:1647\n#4 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=490685453, type=0x7fff72f8cd14, sizep=0x7fff72f8a248) at sha1_file.c:1647\n#5 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=490689484, type=0x7fff72f8cd14, sizep=0x7fff72f8a2c8) at sha1_file.c:1647\n#6 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=490738466, type=0x7fff72f8cd14, sizep=0x7fff72f8a348) at sha1_file.c:1647\n#7 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=490744208, type=0x7fff72f8cd14, sizep=0x7fff72f8a3c8) at sha1_file.c:1647\n#8 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=490755670, type=0x7fff72f8cd14, sizep=0x7fff72f8a448) at sha1_file.c:1647\n#9 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491146004, type=0x7fff72f8cd14, sizep=0x7fff72f8a4c8) at sha1_file.c:1647\n#10 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491148469, type=0x7fff72f8cd14, sizep=0x7fff72f8a548) at sha1_file.c:1647\n#11 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491150324, type=0x7fff72f8cd14, sizep=0x7fff72f8a5c8) at sha1_file.c:1647\n#12 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491150930, type=0x7fff72f8cd14, sizep=0x7fff72f8a648) at sha1_file.c:1647\n#13 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491549282, type=0x7fff72f8cd14, sizep=0x7fff72f8a6c8) at sha1_file.c:1647\n#14 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491552398, type=0x7fff72f8cd14, sizep=0x7fff72f8a748) at sha1_file.c:1647\n#15 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491552652, type=0x7fff72f8cd14, sizep=0x7fff72f8a7c8) at sha1_file.c:1647\n#16 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491553208, type=0x7fff72f8cd14, sizep=0x7fff72f8a848) at sha1_file.c:1647\n#17 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491556704, type=0x7fff72f8cd14, sizep=0x7fff72f8a8c8) at sha1_file.c:1647\n#18 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491560658, type=0x7fff72f8cd14, sizep=0x7fff72f8a948) at sha1_file.c:1647\n#19 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491582507, type=0x7fff72f8cd14, sizep=0x7fff72f8a9c8) at sha1_file.c:1647\n#20 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491604310, type=0x7fff72f8cd14, sizep=0x7fff72f8aa48) at sha1_file.c:1647\n#21 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491614312, type=0x7fff72f8cd14, sizep=0x7fff72f8aac8) at sha1_file.c:1647\n#22 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491666142, type=0x7fff72f8cd14, sizep=0x7fff72f8ab48) at sha1_file.c:1647\n#23 0x0000000000488352 in unpack_entry (p=0x26ad4c0, obj_offset=491901113, type=0x7fff72f8cd14, sizep=0x7fff72f8cd08) at sha1_file.c:1647\n#24 0x00000000004887ca in read_packed_sha1 (sha1=0x336ba64 \"�W\\004�\\037d\\203g��;v\\032vF�>�R�\", type=0x7fff72f8cd14, size=0x7fff72f8cd08) at sha1_file.c:1957\n#25 0x00000000004889fe in read_object (sha1=0x336ba64 \"�W\\004�\\037d\\203g��;v\\032vF�>�R�\", type=0x7fff72f8cd14, size=0x7fff72f8cd08) at sha1_file.c:2047\n#26 0x0000000000488bcc in read_sha1_file (sha1=0x26ad4c0 \"\", type=0x7fff72f8a060, size=0x1d3c923b) at sha1_file.c:2063\n#27 0x000000000048f3fd in parse_tree (item=0x336ba60) at tree.c:224\n#28 0x0000000000423a32 in mark_object (obj=0x336ba60, type=2, data=) at builtin-fsck.c:102\n#29 0x00000000004673bc in fsck_walk (obj=, walk=0x423880 , data=0x336ba38) at fsck.c:26\n#30 0x0000000000423a4a in mark_object (obj=0x336ba38, type=2, data=) at builtin-fsck.c:105\n#31 0x00000000004673bc in fsck_walk (obj=, walk=0x423880 , data=0x66fff78) at fsck.c:26\n#32 0x0000000000423a4a in mark_object (obj=0x66fff78, type=2, data=) at builtin-fsck.c:105\n#33 0x00000000004673bc in fsck_walk (obj=, walk=0x423880 , data=0x66c9a28) at fsck.c:26\n#34 0x0000000000423a4a in mark_object (obj=0x66c9a28, type=2, data=) at builtin-fsck.c:105\n#35 0x0000000000467299 in fsck_walk (obj=0x6bea7b0, walk=0x423880 , data=0x6bea7b0) at fsck.c:50\n#36 0x000000000042390d in mark_object (obj=0x6bea7b0, type=1, data=) at builtin-fsck.c:105\n#37 0x00000000004672d1 in fsck_walk (obj=, walk=0x423880 , data=0x3283fd0) at fsck.c:57\n#38 0x000000000042390d in mark_object (obj=0x3283fd0, type=1, data=) at builtin-fsck.c:105\n#39 0x00000000004672d1 in fsck_walk (obj=, walk=0x423880 , data=0x3283f88) at fsck.c:57\n#40 0x000000000042390d in mark_object (obj=0x3283f88, type=1, data=) at builtin-fsck.c:105\n[...]\n\nThe stack trace in total has about ~80000 frames.\n\nDoes anyone have any suggestions on how to debug this?\n\nThanks,\nSimon\n"},{"id":"96629","messageId":"alpine.LFD.2.00.0811271243250.14328@xanadu.home","threadId":"16502","inReplyTo":"200811271814.06941.simon@lst.de","subject":"Re: git fsck segmentation fault","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-11-27T17:47:41Z","receivedAt":"2008-11-27T17:47:41Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 27 Nov 2008, Simon Hausmann wrote:\n\n> Hi,\n> \n> when running git fsck --full -v (version 1.6.0.4.26.g7c30c) on a medium sized\n\nThat version doesn't exist in the git repo.\n\n> (930M) repository I get a segfault.\n> \n> The backtrace indicates an infinite recursion. Here's the output from the last\n> few lines:\n[...]\n\nCould you try with latest master branch please? It is more robust \nagainst some kind of pack corruptions that could send the code into \ninfinite loops.\n\n\nNicolas\n"},{"id":"96631","messageId":"200811272010.20891.simon@lst.de","threadId":"16502","inReplyTo":"alpine.LFD.2.00.0811271243250.14328@xanadu.home","subject":"Re: git fsck segmentation fault","fromName":"Simon Hausmann","fromEmail":"simon@lst.de","sentAt":"2008-11-27T19:10:20Z","receivedAt":"2008-11-27T19:10:20Z","isPatch":false,"sender":{"key":"hausmann@kde.org","avatar":"https://gravatar.com/avatar/bc9aad4fb31dce17eb66e690e7b51fe980c62da3c225c785da35dd806b8da778?d=mp&s=160"},"body":"On Thursday 27 November 2008 18:47:41 Nicolas Pitre wrote:\n> On Thu, 27 Nov 2008, Simon Hausmann wrote:\n> > Hi,\n> >\n> > when running git fsck --full -v (version 1.6.0.4.26.g7c30c) on a medium\n> > sized\n>\n> That version doesn't exist in the git repo.\n\nAh, oops, it was a merge commit, corresponding to maint as of 5aa3bd.\n\n> > (930M) repository I get a segfault.\n> >\n> > The backtrace indicates an infinite recursion. Here's the output from the\n> > last few lines:\n>\n> [...]\n>\n> Could you try with latest master branch please? It is more robust\n> against some kind of pack corruptions that could send the code into\n> infinite loops.\n\nSame problem with git version 1.6.0.4.790.gaa14a\n\n:-/\n\nSimon\n"},{"id":"96632","messageId":"200811272021.56108.simon@lst.de","threadId":"16502","inReplyTo":"200811272010.20891.simon@lst.de","subject":"Re: git fsck segmentation fault","fromName":"Simon Hausmann","fromEmail":"simon@lst.de","sentAt":"2008-11-27T19:21:55Z","receivedAt":"2008-11-27T19:21:55Z","isPatch":false,"sender":{"key":"hausmann@kde.org","avatar":"https://gravatar.com/avatar/bc9aad4fb31dce17eb66e690e7b51fe980c62da3c225c785da35dd806b8da778?d=mp&s=160"},"body":"On Thursday 27 November 2008 20:10:20 Simon Hausmann wrote:\n> On Thursday 27 November 2008 18:47:41 Nicolas Pitre wrote:\n> > On Thu, 27 Nov 2008, Simon Hausmann wrote:\n> > > Hi,\n> > >\n> > > when running git fsck --full -v (version 1.6.0.4.26.g7c30c) on a medium\n> > > sized\n> >\n> > That version doesn't exist in the git repo.\n>\n> Ah, oops, it was a merge commit, corresponding to maint as of 5aa3bd.\n>\n> > > (930M) repository I get a segfault.\n> > >\n> > > The backtrace indicates an infinite recursion. Here's the output from\n> > > the last few lines:\n> >\n> > [...]\n> >\n> > Could you try with latest master branch please? It is more robust\n> > against some kind of pack corruptions that could send the code into\n> > infinite loops.\n>\n> Same problem with git version 1.6.0.4.790.gaa14a\n\nForgot to paste the changed line numbers of the recursion:\n\n#54 0x0000000000493c6d in parse_tree (item=0x20d0178) at tree.c:224\n#55 0x0000000000424ca2 in mark_object (obj=0x20d0178, type=2, data=) at builtin-fsck.c:102\n#56 0x0000000000468d1c in fsck_walk (obj=, walk=0x424af0 \n, data=0x20d0128) at fsck.c:26\n#57 0x0000000000424cba in mark_object (obj=0x20d0128, type=2, data=) at builtin-fsck.c:105\n#58 0x0000000000468d1c in fsck_walk (obj=, walk=0x424af0 \n, data=0x1edb448) at fsck.c:26\n#59 0x0000000000424cba in mark_object (obj=0x1edb448, type=2, data=) at builtin-fsck.c:105\n#60 0x0000000000468d1c in fsck_walk (obj=, walk=0x424af0 \n, data=0x1edb420) at fsck.c:26\n#61 0x0000000000424cba in mark_object (obj=0x1edb420, type=2, data=) at builtin-fsck.c:105\n#62 0x0000000000468bf9 in fsck_walk (obj=0x241a750, walk=0x424af0 \n, data=0x241a750) at fsck.c:50\n#63 0x0000000000424b7d in mark_object (obj=0x241a750, type=1, data=) at builtin-fsck.c:105\n#64 0x0000000000468c31 in fsck_walk (obj=, walk=0x424af0 \n, data=0x241a708) at fsck.c:57\n#65 0x0000000000424b7d in mark_object (obj=0x241a708, type=1, data=) at builtin-fsck.c:105\n#66 0x0000000000468c31 in fsck_walk (obj=, walk=0x424af0 \n, data=0x4dea0b0) at fsck.c:57\n#67 0x0000000000424b7d in mark_object (obj=0x4dea0b0, type=1, data=) at builtin-fsck.c:105\n#68 0x0000000000468c31 in fsck_walk (obj=, walk=0x424af0 \n, data=0x488ff78) at fsck.c:57\n#69 0x0000000000424b7d in mark_object (obj=0x488ff78, type=1, data=) at builtin-fsck.c:105\n#70 0x0000000000468c31 in fsck_walk (obj=, walk=0x424af0 \n, data=0x488bd18) at fsck.c:57\n#71 0x0000000000424b7d in mark_object (obj=0x488bd18, type=1, data=) at builtin-fsck.c:105\n#72 0x0000000000468c31 in fsck_walk (obj=, walk=0x424af0 \n, data=0x313c0b0) at fsck.c:57\n#73 0x0000000000424b7d in mark_object (obj=0x313c0b0, type=1, data=) at builtin-fsck.c:105\n[recursion between line 105 and 57]\n\nSimon\n"},{"id":"96633","messageId":"alpine.LFD.2.00.0811271449500.14328@xanadu.home","threadId":"16502","inReplyTo":"200811272021.56108.simon@lst.de","subject":"Re: git fsck segmentation fault","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-11-27T19:57:45Z","receivedAt":"2008-11-27T19:57:45Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 27 Nov 2008, Simon Hausmann wrote:\n\n> On Thursday 27 November 2008 20:10:20 Simon Hausmann wrote:\n> > On Thursday 27 November 2008 18:47:41 Nicolas Pitre wrote:\n> > > On Thu, 27 Nov 2008, Simon Hausmann wrote:\n> > > > Hi,\n> > > >\n> > > > when running git fsck --full -v (version 1.6.0.4.26.g7c30c) on a medium\n> > > > sized\n> > >\n> > > That version doesn't exist in the git repo.\n> >\n> > Ah, oops, it was a merge commit, corresponding to maint as of 5aa3bd.\n> >\n> > > > (930M) repository I get a segfault.\n> > > >\n> > > > The backtrace indicates an infinite recursion. Here's the output from\n> > > > the last few lines:\n> > >\n> > > [...]\n> > >\n> > > Could you try with latest master branch please? It is more robust\n> > > against some kind of pack corruptions that could send the code into\n> > > infinite loops.\n> >\n> > Same problem with git version 1.6.0.4.790.gaa14a\n> \n> Forgot to paste the changed line numbers of the recursion:\n[...]\n\nWell... Your initial backtrace showed recursion in unpack_entry() which \nwas rather odd in the first place. Your latest backtrace shows a loop \nin make_object() which has nothing to do what so ever with \nunpack_entry(). So the backtrace might not be really useful.\n\nI suspect you'll have to bisect git to find the issue, given that some \nold version can be found to be good. For example, does it work with \nv1.5.2.5?\n\n\nNicolas\n"},{"id":"96678","messageId":"200811280919.10685.simon@lst.de","threadId":"16502","inReplyTo":"alpine.LFD.2.00.0811271449500.14328@xanadu.home","subject":"Re: git fsck segmentation fault","fromName":"Simon Hausmann","fromEmail":"simon@lst.de","sentAt":"2008-11-28T08:19:09Z","receivedAt":"2008-11-28T08:19:09Z","isPatch":false,"sender":{"key":"hausmann@kde.org","avatar":"https://gravatar.com/avatar/bc9aad4fb31dce17eb66e690e7b51fe980c62da3c225c785da35dd806b8da778?d=mp&s=160"},"body":"On Thursday 27 November 2008 Nicolas Pitre, wrote:\n> On Thu, 27 Nov 2008, Simon Hausmann wrote:\n> > On Thursday 27 November 2008 20:10:20 Simon Hausmann wrote:\n> > > On Thursday 27 November 2008 18:47:41 Nicolas Pitre wrote:\n> > > > On Thu, 27 Nov 2008, Simon Hausmann wrote:\n> > > > > Hi,\n> > > > >\n> > > > > when running git fsck --full -v (version 1.6.0.4.26.g7c30c) on a\n> > > > > medium sized\n> > > >\n> > > > That version doesn't exist in the git repo.\n> > >\n> > > Ah, oops, it was a merge commit, corresponding to maint as of 5aa3bd.\n> > >\n> > > > > (930M) repository I get a segfault.\n> > > > >\n> > > > > The backtrace indicates an infinite recursion. Here's the output\n> > > > > from the last few lines:\n> > > >\n> > > > [...]\n> > > >\n> > > > Could you try with latest master branch please? It is more robust\n> > > > against some kind of pack corruptions that could send the code into\n> > > > infinite loops.\n> > >\n> > > Same problem with git version 1.6.0.4.790.gaa14a\n> >\n> > Forgot to paste the changed line numbers of the recursion:\n>\n> [...]\n>\n> Well... Your initial backtrace showed recursion in unpack_entry() which\n> was rather odd in the first place. Your latest backtrace shows a loop\n> in make_object() which has nothing to do what so ever with\n> unpack_entry(). So the backtrace might not be really useful.\n>\n> I suspect you'll have to bisect git to find the issue, given that some\n> old version can be found to be good. For example, does it work with\n> v1.5.2.5?\n\nAh yes, v1.5.2.5 works! (phew, and it verified that the repo is fine)\n\nOk, I bisected and \"git bisect run\" identified the following commit as first bad \ncommit:\n\ncommit 271b8d25b25e49b367087440e093e755e5f35aa9\nAuthor: Martin Koegler \nDate: Mon Feb 25 22:46:05 2008 +0100\n\n builtin-fsck: move away from object-refs to fsck_walk\n\n\n\n\nSimon\n"},{"id":"97447","messageId":"alpine.LFD.2.00.0812091408560.14328@xanadu.home","threadId":"16502","inReplyTo":"200811280919.10685.simon@lst.de","subject":"Re: git fsck segmentation fault","fromName":"Nicolas Pitre","fromEmail":"nico@cam.org","sentAt":"2008-12-09T19:09:58Z","receivedAt":"2008-12-09T19:09:58Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"\nHas this been looked at? Martin?\n\nOn Fri, 28 Nov 2008, Simon Hausmann wrote:\n\n> On Thursday 27 November 2008 Nicolas Pitre, wrote:\n> > On Thu, 27 Nov 2008, Simon Hausmann wrote:\n> > > On Thursday 27 November 2008 20:10:20 Simon Hausmann wrote:\n> > > > On Thursday 27 November 2008 18:47:41 Nicolas Pitre wrote:\n> > > > > On Thu, 27 Nov 2008, Simon Hausmann wrote:\n> > > > > > Hi,\n> > > > > >\n> > > > > > when running git fsck --full -v (version 1.6.0.4.26.g7c30c) on a\n> > > > > > medium sized\n> > > > >\n> > > > > That version doesn't exist in the git repo.\n> > > >\n> > > > Ah, oops, it was a merge commit, corresponding to maint as of 5aa3bd.\n> > > >\n> > > > > > (930M) repository I get a segfault.\n> > > > > >\n> > > > > > The backtrace indicates an infinite recursion. Here's the output\n> > > > > > from the last few lines:\n> > > > >\n> > > > > [...]\n> > > > >\n> > > > > Could you try with latest master branch please? It is more robust\n> > > > > against some kind of pack corruptions that could send the code into\n> > > > > infinite loops.\n> > > >\n> > > > Same problem with git version 1.6.0.4.790.gaa14a\n> > >\n> > > Forgot to paste the changed line numbers of the recursion:\n> >\n> > [...]\n> >\n> > Well... Your initial backtrace showed recursion in unpack_entry() which\n> > was rather odd in the first place. Your latest backtrace shows a loop\n> > in make_object() which has nothing to do what so ever with\n> > unpack_entry(). So the backtrace might not be really useful.\n> >\n> > I suspect you'll have to bisect git to find the issue, given that some\n> > old version can be found to be good. For example, does it work with\n> > v1.5.2.5?\n> \n> Ah yes, v1.5.2.5 works! (phew, and it verified that the repo is fine)\n> \n> Ok, I bisected and \"git bisect run\" identified the following commit as first bad \n> commit:\n> \n> commit 271b8d25b25e49b367087440e093e755e5f35aa9\n> Author: Martin Koegler \n> Date: Mon Feb 25 22:46:05 2008 +0100\n> \n> builtin-fsck: move away from object-refs to fsck_walk\n> \n> \n> \n> \n> Simon\n> \n"},{"id":"97455","messageId":"20081209215722.GA8877@auto.tuwien.ac.at","threadId":"16502","inReplyTo":"alpine.LFD.2.00.0812091408560.14328@xanadu.home","subject":"Re: git fsck segmentation fault","fromName":"Martin Koegler","fromEmail":"mkoegler@auto.tuwien.ac.at","sentAt":"2008-12-09T21:57:22Z","receivedAt":"2008-12-09T21:57:22Z","isPatch":false,"sender":{"key":"mkoegler@auto.tuwien.ac.at","avatar":null},"body":"On Tue, Dec 09, 2008 at 02:09:58PM -0500, Nicolas Pitre wrote:\n> Has this been looked at? Martin?\n\nI have not noticed this message.\n\n> #54 0x0000000000493c6d in parse_tree (item=0x20d0178) at tree.c:224\n> #55 0x0000000000424ca2 in mark_object (obj=0x20d0178, type=2, data= optimized out>) at builtin-fsck.c:102\n> #56 0x0000000000468d1c in fsck_walk (obj=, walk=0x424af0 \n> , data=0x20d0128) at fsck.c:26\n> #57 0x0000000000424cba in mark_object (obj=0x20d0128, type=2, data= optimized out>) at builtin-fsck.c:105\n> #58 0x0000000000468d1c in fsck_walk (obj=, walk=0x424af0 \n> , data=0x1edb448) at fsck.c:26\n> #59 0x0000000000424cba in mark_object (obj=0x1edb448, type=2, data= optimized out>) at builtin-fsck.c:105\n> #60 0x0000000000468d1c in fsck_walk (obj=, walk=0x424af0 \n> , data=0x1edb420) at fsck.c:26\n> #61 0x0000000000424cba in mark_object (obj=0x1edb420, type=2, data= optimized out>) at builtin-fsck.c:105\n> #62 0x0000000000468bf9 in fsck_walk (obj=0x241a750, walk=0x424af0 \n> , data=0x241a750) at fsck.c:50\n> #63 0x0000000000424b7d in mark_object (obj=0x241a750, type=1, data= optimized out>) at builtin-fsck.c:105\n> #64 0x0000000000468c31 in fsck_walk (obj=, walk=0x424af0 \n> , data=0x241a708) at fsck.c:57\n> #65 0x0000000000424b7d in mark_object (obj=0x241a708, type=1, data= optimized out>) at builtin-fsck.c:105\n> #66 0x0000000000468c31 in fsck_walk (obj=, walk=0x424af0 \n> , data=0x4dea0b0) at fsck.c:57\n> #67 0x0000000000424b7d in mark_object (obj=0x4dea0b0, type=1, data= optimized out>) at builtin-fsck.c:105\n> #68 0x0000000000468c31 in fsck_walk (obj=, walk=0x424af0 \n> , data=0x488ff78) at fsck.c:57\n> #69 0x0000000000424b7d in mark_object (obj=0x488ff78, type=1, data= optimized out>) at builtin-fsck.c:105\n> #70 0x0000000000468c31 in fsck_walk (obj=, walk=0x424af0 \n> , data=0x488bd18) at fsck.c:57\n> #71 0x0000000000424b7d in mark_object (obj=0x488bd18, type=1, data= optimized out>) at builtin-fsck.c:105\n> #72 0x0000000000468c31 in fsck_walk (obj=, walk=0x424af0 \n> , data=0x313c0b0) at fsck.c:57\n> #73 0x0000000000424b7d in mark_object (obj=0x313c0b0, type=1, data= optimized out>) at builtin-fsck.c:105\n> [recursion between line 105 and 57]\n\nIf I look at the backtrace, nothing seems wrong. The obj pointers for\nmark_object are all different, so its not stuck in a loop. If you look\nat type, you will see that it traverses commits (type=1) untils\n#63. Then it traverses trees (type=2).\n\nAt my option, there is a commit with a very long ancestory (~40.000\n[stack frame count/2]). As we do depth first search for the reachability\ncheck, we need about 80.000 frames.\n\nI suggest, that you retry with a very much bigger stack (ulimit -s).\n\nmfg Martin Kögler\n"},{"id":"97470","messageId":"20081210075338.GA7776@auto.tuwien.ac.at","threadId":"16502","inReplyTo":"alpine.LFD.2.00.0812091408560.14328@xanadu.home","subject":"Re: git fsck segmentation fault","fromName":"Martin Koegler","fromEmail":"mkoegler@auto.tuwien.ac.at","sentAt":"2008-12-10T07:53:38Z","receivedAt":"2008-12-10T07:53:38Z","isPatch":false,"sender":{"key":"mkoegler@auto.tuwien.ac.at","avatar":null},"body":"Maybe something like this could help:\n\n>From 32be177cbb0825fc019200b172f3d79117b28140 Mon Sep 17 00:00:00 2001\nFrom: Martin Koegler \nDate: Wed, 10 Dec 2008 08:42:08 +0100\nSubject: [PATCH] fsck: use fewer stack\n\nThis patch moves the state while traversing the tree\nfrom the stack to the heap.\n\nNot-really-tested-by: Martin Koegler\nSigned-off-by: Martin Koegler \n---\n builtin-fsck.c | 19 +++++++++++++++++--\n 1 files changed, 17 insertions(+), 2 deletions(-)\n\ndiff --git a/builtin-fsck.c b/builtin-fsck.c\nindex afded5e..8184699 100644\n--- a/builtin-fsck.c\n+++ b/builtin-fsck.c\n@@ -36,6 +36,9 @@ static int verbose;\n #define DIRENT_SORT_HINT(de) ((de)->d_ino)\n #endif\n \n+static int objectstack_nr, objectstack_alloc;\n+struct object **objectstack;\n+\n static void objreport(struct object *obj, const char *severity,\n const char *err, va_list params)\n {\n@@ -66,9 +69,7 @@ static int fsck_error_func(struct object *obj, int type, const char *err, ...)\n \n static int mark_object(struct object *obj, int type, void *data)\n {\n-\tstruct tree *tree = NULL;\n \tstruct object *parent = data;\n-\tint result;\n \n \tif (!obj) {\n \t\tprintf(\"broken link from %7s %s\\n\",\n@@ -95,6 +96,15 @@ static int mark_object(struct object *obj, int type, void *data)\n \t\t}\n \t\treturn 1;\n \t}\n+\tALLOC_GROW(objectstack, objectstack_nr + 1, objectstack_alloc);\n+\tobjectstack[objectstack_nr++] = obj;\n+\treturn 0;\n+}\n+\n+static int mark_child_object(struct object *obj)\n+{\n+\tstruct tree *tree = NULL;\n+\tint result;\n \n \tif (obj->type == OBJ_TREE) {\n \t\tobj->parsed = 0;\n@@ -116,6 +126,11 @@ static int mark_object(struct object *obj, int type, void *data)\n static void mark_object_reachable(struct object *obj)\n {\n \tmark_object(obj, OBJ_ANY, 0);\n+\twhile (objectstack_nr > 0) {\n+\t\tstruct object *obj = objectstack[--objectstack_nr];\n+\t\tif (mark_child_object(obj) < 0)\n+\t\t\tbreak;\n+\t}\n }\n \n static int mark_used(struct object *obj, int type, void *data)\n-- \n1.6.1.rc2.283.g32be1\n"},{"id":"97568","messageId":"7vljunwidr.fsf@gitster.siamese.dyndns.org","threadId":"16502","inReplyTo":"20081210075338.GA7776@auto.tuwien.ac.at","subject":"Re: git fsck segmentation fault","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-11T02:33:20Z","receivedAt":"2008-12-11T02:33:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"mkoegler@auto.tuwien.ac.at (Martin Koegler) writes:\n\n> Maybe something like this could help:\n\n>>From 32be177cbb0825fc019200b172f3d79117b28140 Mon Sep 17 00:00:00 2001\n> From: Martin Koegler \n> Date: Wed, 10 Dec 2008 08:42:08 +0100\n> Subject: [PATCH] fsck: use fewer stack\n>\n> This patch moves the state while traversing the tree\n> from the stack to the heap.\n\nHmm, after the change:\n\n\t* mark_object() marks the object as reachable, and pushes the\n\t objects to the objectstack;\n\n\t* mark_object_reachable() marks the object using mark_object(),\n and repeatedly calls mark_child_object() until the objectstack\n is fully drained;\n\n\t* mark_child_object() inspects the object taken from the\n objectstack, calls fsck_walk() on it, with mark_object as the\n callback;\n\n\t * fsck_walk() calls the callback function (i.e. mark_object) on\n the object given, and the objects immediately reachable from\n it;\n\n * mark_object() does not recurse, so these immediately\n reachable objects are left in the objectstack, without a\n deep recursion.\n \nThat seems to be what is going on, and this should be a good fix.\n\nA similar change would be needed for other callers of fsck_walk(), no?\nThere seem to be one in builtin-unpack-objects.c (check_object calls\nfsck_walk as itself as the callback). \n\nAnother caller is in index-pack.c (sha1_object() calls fsck_walk with\nmark_link as the callback), but I do not think it would recurse for the\ndepth of the history, so we are safe there.\n\nI initially expected that the fix would be to introduce this \"userspace\nwork queue\" (i.e. your objectstack) to be maintained on the\nfsck.c:fsck_walk() side (perhaps as an extra parameter to an actual queue\nfor reentrancy), not by making the callee not to recurse, though.\n"},{"id":"97580","messageId":"20081211062753.GA17683@auto.tuwien.ac.at","threadId":"16502","inReplyTo":"7vljunwidr.fsf@gitster.siamese.dyndns.org","subject":"Re: git fsck segmentation fault","fromName":"Martin Koegler","fromEmail":"mkoegler@auto.tuwien.ac.at","sentAt":"2008-12-11T06:27:53Z","receivedAt":"2008-12-11T06:27:53Z","isPatch":false,"sender":{"key":"mkoegler@auto.tuwien.ac.at","avatar":null},"body":"On Wed, Dec 10, 2008 at 06:33:20PM -0800, Junio C Hamano wrote:\n> mkoegler@auto.tuwien.ac.at (Martin Koegler) writes:\n> A similar change would be needed for other callers of fsck_walk(), no?\n> There seem to be one in builtin-unpack-objects.c (check_object calls\n> fsck_walk as itself as the callback). \n\nbuitin-unpack-objects.c is different. First, its intended for the\nsmall case [default unpack_limit is 100; it keeps the unpacked content\nof trees/commits in memory], which will not overflow the\nstack. Second, it may only write an object after all of its connected\nobjects have been written out. So it would need a totally different\nlogic.\n\n> Another caller is in index-pack.c (sha1_object() calls fsck_walk with\n> mark_link as the callback), but I do not think it would recurse for the\n> depth of the history, so we are safe there.\n\nmark_link only sets a flag on the direct connected objects, so yes, it\nneeds no change.\n\n> I initially expected that the fix would be to introduce this \"userspace\n> work queue\" (i.e. your objectstack) to be maintained on the\n> fsck.c:fsck_walk() side (perhaps as an extra parameter to an actual queue\n> for reentrancy), not by making the callee not to recurse, though.\n\nfsck_walk has been designed to call a function on all directly\nconnected objected. There are callers, which expected this behaviour\n(eg. index-pack, mark_used in fsck).\n\nmfg Martin Kögler\n"},{"id":"97581","messageId":"7v1vwfw6u7.fsf@gitster.siamese.dyndns.org","threadId":"16502","inReplyTo":"20081211062753.GA17683@auto.tuwien.ac.at","subject":"Re: git fsck segmentation fault","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-12-11T06:42:40Z","receivedAt":"2008-12-11T06:42:40Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"mkoegler@auto.tuwien.ac.at (Martin Koegler) writes:\n\n> fsck_walk has been designed to call a function on all directly\n> connected objected. There are callers, which expected this behaviour\n> (eg. index-pack, mark_used in fsck).\n\nYes, that is where my \"initially expected\" comes from. I was not\ncomplaining or suggesting the behaviour to change.\n\nI was fooled by the word *walk* in the name, which implies an\nimplementation of walking connectivity fully, with or without an ability\nfor the callback to tell the machinery when to or not to dig deeper. It\nwouldn't have been confusing if it were named \"fsck_step()\", which is what\nthe function is about: performing a single step of digging deeper.\n"}]}