{"thread":{"id":"51546","subject":"git name-rev segfault","startedAt":"2019-07-29T14:19:54Z","lastAt":"2019-07-29T20:00:53Z","messageCount":3,"participants":["Tamas Papp","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"379501","messageId":"799a4ba4-a2ae-7ce3-a6e4-acd329d062da@rtfm.co.hu","threadId":"51546","inReplyTo":null,"subject":"git name-rev segfault","fromName":"Tamas Papp","fromEmail":"tamas.papp@rtfm.co.hu","sentAt":"2019-07-29T14:19:47Z","receivedAt":"2019-07-29T14:19:54Z","isPatch":false,"sender":{"key":"tamas.papp@rtfm.co.hu","avatar":null},"body":"hi All,\n\n\nWe ran into a segfault with all version of command line git.\n\nWe are able to reproduce this issue by this way:\n\n\nGenerate 100k file into a repository:\n\n#!/bin/bash\n\nrm -rf .git test.file\ngit init\ngit config user.email a@b\ngit config user.name c\n\ntime for i in {1..100000}\ndo\n   [ $((i % 2)) -eq 1 ] && echo $i>test.file || echo 0 >test.file\n   git add test.file\n\n   git commit -m \"$i committed\"\n\ndone\n\n\nRun git on it:\n\n$ git name-rev a20f6989b75fa63ec6259a988e38714e1f5328a0\n\n\n\nCould you coment on it?\n\n\nThank you,\n\ntamas\n\n"},{"id":"379515","messageId":"20190729195001.GE14943@sigill.intra.peff.net","threadId":"51546","inReplyTo":"799a4ba4-a2ae-7ce3-a6e4-acd329d062da@rtfm.co.hu","subject":"Re: git name-rev segfault","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2019-07-29T19:50:02Z","receivedAt":"2019-07-29T19:50:04Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Jul 29, 2019 at 04:19:47PM +0200, Tamas Papp wrote:\n\n> Generate 100k file into a repository:\n> \n> #!/bin/bash\n> \n> rm -rf .git test.file\n> git init\n> git config user.email a@b\n> git config user.name c\n> \n> time for i in {1..100000}\n> do\n>   [ $((i % 2)) -eq 1 ] && echo $i>test.file || echo 0 >test.file\n>   git add test.file\n> \n>   git commit -m \"$i committed\"\n> \n> done\n\nI lost patience kicking off two hundred thousand processes. Try this:\n\n  for i in {1..100000}\n  do\n    echo \"commit HEAD\"\n    echo \"committer c <a@b> $i +0000\"\n    echo \"data <<EOF\"\n    echo \"$i committed\"\n    echo \"EOF\"\n    echo\n  done | git fast-import\n\nwhich runs much faster. This doesn't change any files in each commit,\nbut I don't think it's necessary for what you're showing (name-rev\nwouldn't ever look at the trees).\n\n> Run git on it:\n> \n> $ git name-rev a20f6989b75fa63ec6259a988e38714e1f5328a0\n\nAnybody who runs your script will get a different sha1 because of the\nchange in timestamps. I guess this is HEAD, though. I also needed to\nhave an actual tag to find. So:\n\n  git tag old-tag HEAD~99999\n  git name-rev HEAD\n\nsegfaults for me.\n\n> Could you coment on it?\n\nThis is a known issue. The algorithm used by name-rev is recursive, and\nyou can run out of stack space in some deep cases. There's more\ndiscussion this thread:\n\n  https://public-inbox.org/git/6a4cbbee-ffc6-739b-d649-079ba01439ca@grubix.eu/\n\nincluding some patches that document the problem with an expected\nfailure in our test suite. Nobody has actually rewritten the C code yet,\nthough.\n\n-Peff\n"},{"id":"379518","messageId":"560b857a-808e-9ac6-ec3e-6778bb4c03e7@rtfm.co.hu","threadId":"51546","inReplyTo":"20190729195001.GE14943@sigill.intra.peff.net","subject":"Re: git name-rev segfault","fromName":"Tamas Papp","fromEmail":"tamas.papp@rtfm.co.hu","sentAt":"2019-07-29T20:00:40Z","receivedAt":"2019-07-29T20:00:53Z","isPatch":false,"sender":{"key":"tamas.papp@rtfm.co.hu","avatar":null},"body":"Thanks for letting me know and for the corrections too.\n\n\nCheers,\n\ntamas\n\n\nOn 7/29/19 9:50 PM, Jeff King wrote:\n> On Mon, Jul 29, 2019 at 04:19:47PM +0200, Tamas Papp wrote:\n>\n>> Generate 100k file into a repository:\n>>\n>> #!/bin/bash\n>>\n>> rm -rf .git test.file\n>> git init\n>> git config user.email a@b\n>> git config user.name c\n>>\n>> time for i in {1..100000}\n>> do\n>>    [ $((i % 2)) -eq 1 ] && echo $i>test.file || echo 0 >test.file\n>>    git add test.file\n>>\n>>    git commit -m \"$i committed\"\n>>\n>> done\n> I lost patience kicking off two hundred thousand processes. Try this:\n>\n>    for i in {1..100000}\n>    do\n>      echo \"commit HEAD\"\n>      echo \"committer c <a@b> $i +0000\"\n>      echo \"data <<EOF\"\n>      echo \"$i committed\"\n>      echo \"EOF\"\n>      echo\n>    done | git fast-import\n>\n> which runs much faster. This doesn't change any files in each commit,\n> but I don't think it's necessary for what you're showing (name-rev\n> wouldn't ever look at the trees).\n>\n>> Run git on it:\n>>\n>> $ git name-rev a20f6989b75fa63ec6259a988e38714e1f5328a0\n> Anybody who runs your script will get a different sha1 because of the\n> change in timestamps. I guess this is HEAD, though. I also needed to\n> have an actual tag to find. So:\n>\n>    git tag old-tag HEAD~99999\n>    git name-rev HEAD\n>\n> segfaults for me.\n>\n>> Could you coment on it?\n> This is a known issue. The algorithm used by name-rev is recursive, and\n> you can run out of stack space in some deep cases. There's more\n> discussion this thread:\n>\n>    https://public-inbox.org/git/6a4cbbee-ffc6-739b-d649-079ba01439ca@grubix.eu/\n>\n> including some patches that document the problem with an expected\n> failure in our test suite. Nobody has actually rewritten the C code yet,\n> though.\n>\n> -Peff\n"}]}