{"thread":{"id":"41766","subject":"git master describe segfault","startedAt":"2016-03-21T09:35:05Z","lastAt":"2016-03-21T19:31:16Z","messageCount":2,"participants":["Daniel Stenberg","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"281336","messageId":"alpine.DEB.2.20.1603211025330.20859@tvnag.unkk.fr","threadId":"41766","inReplyTo":null,"subject":"git master describe segfault","fromName":"Daniel Stenberg","fromEmail":"daniel@haxx.se","sentAt":"2016-03-21T09:35:05Z","receivedAt":"2016-03-21T09:35:05Z","isPatch":false,"sender":{"key":"daniel@haxx.se","avatar":"https://gravatar.com/avatar/69fdca87edd17cee21ca2e79fc2ff671d644603c3dc27167430f3cd3dbab7ba8?d=mp&s=160"},"body":"Hello good peeps!\n\nI just ran head-first into a segfault that is fully reproducable for me but \nI'm not at all fluent in these internals so I'm not the suitable person to \noffer a fix. Let me instead offer you some fine details:\n\n0. I'm on a Linux box: a reasonably updated Debian unstable.\n\n1. I'm up to date with the latest git master branch of gecko-dev: \nhttps://github.com/mozilla/gecko-dev (counting a little over 467K commits)\n\n2. I built the current git off the master branch (v2.8.0-rc3-12-g047057b)\n\n3. In the gecko-dev dir, I run 'git describe --contains f495d0cc2'\n\nThe outcome is what looks like a fine stack smash due to very very extensive \nrecursion:\n\n$ gdb --args ../git/git describe --contains f495d0cc2\n(gdb) run\nProgram received signal SIGSEGV, Segmentation fault.\n0x00007ffff7bccf73 in ?? () from /lib/x86_64-linux-gnu/libz.so.1\n#0  0x00007ffff7bccf73 in ?? () from /lib/x86_64-linux-gnu/libz.so.1\n#1  0x00007ffff7bcc233 in inflate () from /lib/x86_64-linux-gnu/libz.so.1\n#2  0x00000000005935d6 in git_inflate (strm=0x7fffff7ff1d0, flush=4) at \nzlib.c:118\n#3  0x000000000055d2fd in unpack_compressed_entry (p=0x886b00, \nw_curs=0x7fffff7ff8e8, curpos=83902121, size=242) at sha1_file.c:2087\n#4  0x000000000055dcbb in unpack_entry (p=0x886b00, obj_offset=83902119, \nfinal_type=0x7fffff7ffb50, final_size=0x7fffff7ffb48) at sha1_file.c:2341\n#5  0x000000000055d533 in cache_or_unpack_entry (p=0x886b00, \nbase_offset=83902119, base_size=0x7fffff7ffb48, type=0x7fffff7ffb50, \nkeep_cache=1) at sha1_file.c:2165\n#6  0x000000000055ed88 in read_packed_sha1 (sha1=0x170df24 \n\"w\\367\\026,ũD\\362\\b4\\001{\\216\\b[\\255\\261\", <incomplete sequence \\335>, \ntype=0x7fffff7ffb50, size=0x7fffff7ffb48) at sha1_file.c:2789\n#7  0x000000000055f01b in read_object (sha1=0x170df24 \n\"w\\367\\026,ũD\\362\\b4\\001{\\216\\b[\\255\\261\", <incomplete sequence \\335>, \ntype=0x7fffff7ffb50, size=0x7fffff7ffb48) at sha1_file.c:2837\n#8  0x000000000055f0f3 in read_sha1_file_extended (sha1=0x170df24 \n\"w\\367\\026,ũD\\362\\b4\\001{\\216\\b[\\255\\261\", <incomplete sequence \\335>, \ntype=0x7fffff7ffb50, size=0x7fffff7ffb48, flag=1) at sha1_file.c:2865\n#9  0x00000000004b1e2b in read_sha1_file (sha1=0x170df24 \n\"w\\367\\026,ũD\\362\\b4\\001{\\216\\b[\\255\\261\", <incomplete sequence \\335>, \ntype=0x7fffff7ffb50, size=0x7fffff7ffb48) at cache.h:1008\n#10 0x00000000004b2fc9 in parse_commit_gently (item=0x170df20, \nquiet_on_missing=0) at commit.c:383\n#11 0x0000000000464627 in parse_commit (item=0x170df20) at ./commit.h:65\n#12 0x0000000000464662 in name_rev (commit=0x170df20, tip_name=0x8e9170 \n\"B2G_1_0_0_20130115070201\", generation=87254, distance=87254, deref=0) at \nbuiltin/name-rev.c:30\n#13 0x00000000004647de in name_rev (commit=0x170dee0, tip_name=0x8e9170 \n\"B2G_1_0_0_20130115070201\", generation=87253, distance=87253, deref=0) at \nbuiltin/name-rev.c:72\n#14 0x00000000004647de in name_rev (commit=0x170dea0, tip_name=0x8e9170 \n\"B2G_1_0_0_20130115070201\", generation=87252, distance=87252, deref=0) at \nbuiltin/name-rev.c:72\n#15 0x00000000004647de in name_rev (commit=0x170de60, tip_name=0x8e9170 \n\"B2G_1_0_0_20130115070201\", generation=87251, distance=87251, deref=0) at \nbuiltin/name-rev.c:72\n#16 0x00000000004647de in name_rev (commit=0x170de20, tip_name=0x8e9170 \n\"B2G_1_0_0_20130115070201\", generation=87250, distance=87250, deref=0) at \nbuiltin/name-rev.c:72\n#17 0x00000000004647de in name_rev (commit=0x170dde0, tip_name=0x8e9170 \n\"B2G_1_0_0_20130115070201\", generation=87249, distance=87249, deref=0) at \nbuiltin/name-rev.c:72\n\n...\n\n#35070 0x00000000004647de in name_rev (commit=0x1172250, tip_name=0x8e9170 \n\"B2G_1_0_0_20130115070201\", generation=52196, distance=52196, deref=0) at \nbuiltin/name-rev.c:72\n#35071 0x00000000004647de in name_rev (commit=0x1172210, tip_name=0x8e9170 \n\"B2G_1_0_0_20130115070201\", generation=52195, distance=52195, deref=0) at \nbuiltin/name-rev.c:72\n#35072 0x00000000004647de in name_rev (commit=0x11721d0, tip_name=0x8e9170 \n\"B2G_1_0_0_20130115070201\", generation=52194, distance=52194, deref=0) at \nbuiltin/name-rev.c:72\n\n...\n\nand so on, I actually didn't bother to find the end of this but logically I'd \nguess there was about 52194 more stack frames to go!\n\n(gdb) fr 2\n#2  0x00000000005935d6 in git_inflate (strm=0x7fffff7ff1d0, flush=4) at \nzlib.c:118\n118                     status = inflate(&strm->z,\n(gdb) list\n113             int status;\n114\n115             for (;;) {\n116                     zlib_pre_call(strm);\n117                     /* Never say Z_FINISH unless we are feeding everything \n*/\n118                     status = inflate(&strm->z,\n119                                      (strm->z.avail_in != strm->avail_in)\n120                                      ? 0 : flush);\n121                     if (status == Z_MEM_ERROR)\n122                             die(\"inflate: out of memory\");\n\n... and the 'strm' struct looks fine to a layman like me:\n\n(gdb) p *strm\n$2 = {z = {\n     next_in = 0x7fffb234bea9 \"x\\234\\245\\216\\273\\n\\003!\\020E{\\277\\302&U \n8\\263\\352(\\204\\374\\213\\343\\003\\267\\330U\\304@>?n\\237.\\267<\\\\\\016g\\216\\234%\\030\\353-%\\364D\\314X\\210\\302\\226\\031t\\214\\316C\\304d\\035\\004\\255\\vZ\\321\\303\\310\\347\\224T\\b\\301\\220\\211\\224La&}\\235\\213\\\"`\\334,+\\214X\\034{mDx\\317چ\\254}\\204T\\303y\\253m\\366\\326\\037\\261\\035\\362\\371\\003\\276$(G\\236\\064lV\\336՚X\\364\\330\\347\\314\\177ID\\331?\\362\\062\\255x\\361\\005\\272qJ\\206\\225\\022x\\234\\245\\214\\061n\\304 \n\\020\", avail_in = 989839703, total_in = 0, next_out = 0x15d1920 \n\"x+3\\367\\377\\177\", avail_out = 243, total_out = 0, msg = 0x0, state = \n0x1728cd0, zalloc = 0x7ffff7bd0000, zfree = 0x7ffff7bd0010,\n     opaque = 0x0, data_type = 0, adler = 1, reserved = 0}, avail_in = \n989839703, avail_out = 243, total_in = 0, total_out = 0,\n   next_in = 0x7fffb234bea9 \"x\\234\\245\\216\\273\\n\\003!\\020E{\\277\\302&U \n8\\263\\352(\\204\\374\\213\\343\\003\\267\\330U\\304@>?n\\237.\\267<\\\\\\016g\\216\\234%\\030\\353-%\\364D\\314X\\210\\302\\226\\031t\\214\\316C\\304d\\035\\004\\255\\vZ\\321\\303\\310\\347\\224T\\b\\301\\220\\211\\224La&}\\235\\213\\\"`\\334,+\\214X\\034{mDx\\317چ\\254}\\204T\\303y\\253m\\366\\326\\037\\261\\035\\362\\371\\003\\276$(G\\236\\064lV\\336՚X\\364\\330\\347\\314\\177ID\\331?\\362\\062\\255x\\361\\005\\272qJ\\206\\225\\022x\\234\\245\\214\\061n\\304 \n\\020\", next_out = 0x15d1920 \"x+3\\367\\377\\177\"}\n\n\nLet me know what else I can do to help anyone figure this out!\n\n-- \n\n  / daniel.haxx.se"},{"id":"281366","messageId":"xmqqzitrljaz.fsf@gitster.mtv.corp.google.com","threadId":"41766","inReplyTo":"alpine.DEB.2.20.1603211025330.20859@tvnag.unkk.fr","subject":"Re: git master describe segfault","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-03-21T19:31:16Z","receivedAt":"2016-03-21T19:31:16Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Stenberg <daniel@haxx.se> writes:\n\n> 0. I'm on a Linux box: a reasonably updated Debian unstable.\n>\n> 1. I'm up to date with the latest git master branch of gecko-dev:\n> https://github.com/mozilla/gecko-dev (counting a little over 467K\n> commits)\n>\n> 2. I built the current git off the master branch (v2.8.0-rc3-12-g047057b)\n>\n> 3. In the gecko-dev dir, I run 'git describe --contains f495d0cc2'\n>\n> The outcome is what looks like a fine stack smash due to very very\n> extensive recursion:\n>\n> $ gdb --args ../git/git describe --contains f495d0cc2\n> (gdb) run\n> Program received signal SIGSEGV, Segmentation fault.\n> 0x00007ffff7bccf73 in ?? () from /lib/x86_64-linux-gnu/libz.so.1\n> ...\n> #12 0x0000000000464662 in name_rev (commit=0x170df20,\n> tip_name=0x8e9170 \"B2G_1_0_0_20130115070201\", generation=87254,\n> distance=87254, deref=0) at builtin/name-rev.c:30\n> #13 0x00000000004647de in name_rev (commit=0x170dee0,\n> tip_name=0x8e9170 \"B2G_1_0_0_20130115070201\", generation=87253,\n> distance=87253, deref=0) at builtin/name-rev.c:72\n> #14 0x00000000004647de in name_rev (commit=0x170dea0,\n> tip_name=0x8e9170 \"B2G_1_0_0_20130115070201\", generation=87252,\n> distance=87252, deref=0) at builtin/name-rev.c:72\n> #15 0x00000000004647de in name_rev (commit=0x170de60,\n> tip_name=0x8e9170 \"B2G_1_0_0_20130115070201\", generation=87251,\n> distance=87251, deref=0) at builtin/name-rev.c:72\n> #16 0x00000000004647de in name_rev (commit=0x170de20,\n> tip_name=0x8e9170 \"B2G_1_0_0_20130115070201\", generation=87250,\n> distance=87250, deref=0) at builtin/name-rev.c:72\n> #17 0x00000000004647de in name_rev (commit=0x170dde0,\n> tip_name=0x8e9170 \"B2G_1_0_0_20130115070201\", generation=87249,\n> distance=87249, deref=0) at builtin/name-rev.c:72\n\nIt does look bad.  name_rev() naively recurses quite a lot and\neasily runs out of stack space, it seems (rewriting the recursion\nto iterative implementation may help).  I haven't looked at this\ncode carefully for quite a while, but I suspect piece of memory\npointed at by new_name variable may also be leaking.\n \n"}]}