{"thread":{"id":"33107","subject":"Memory corruption when rebasing with git version 1.8.1.5 on arch","startedAt":"2013-03-08T12:19:57Z","lastAt":"2013-03-22T21:24:21Z","messageCount":14,"participants":["Bernhard Posselt","Jeff King","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"210833","messageId":"5139D76D.80703@bernhard-posselt.com","threadId":"33107","inReplyTo":null,"subject":"Memory corruption when rebasing with git version 1.8.1.5 on arch","fromName":"Bernhard Posselt","fromEmail":"mail@bernhard-posselt.com","sentAt":"2013-03-08T12:19:57Z","receivedAt":"2013-03-08T12:19:57Z","isPatch":false,"sender":{"key":"mail@bernhard-posselt.com","avatar":null},"body":"Hi im running arch linux and core/glibc 2.17-3\n\nWhen i try to rebase with:\n\ngit clonehttps://github.com/owncloud/core.git\ncd core/\ngit pull --rebasehttps://github.com/PatrickHeller/core.git  master\n\nI'm getting:\n\n$ git pull --rebasehttps://github.com/PatrickHeller/core.git  master\nremote: Counting objects: 5, done.\nremote: Compressing objects: 100% (1/1), done.\nremote: Total 3 (delta 2), reused 3 (delta 2)\nUnpacking objects: 100% (3/3), done.\n  Fromhttps://github.com/PatrickHeller/core\n   * branch            master     -> FETCH_HEAD\nFirst, rewinding head to replay your work on top of it...\nApplying: distinguish between touch and write\nApplying: remove debug output\n*** Error in `git': malloc(): memory corruption: 0x0000000000be14e0 ***\n\n\nUsing valgrind gives me:\n\n$ valgrind /usr/bin/git pull --rebasehttps://github.com/PatrickHeller/core.git  master\n==5995== Memcheck, a memory error detector\n==5995== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.\n==5995== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info\n==5995== Command: /usr/bin/git pull --rebasehttps://github.com/PatrickHeller/core.git  master\n==5995==\nremote: Counting objects: 5, done.\nremote: Compressing objects: 100% (1/1), done.\nremote: Total 3 (delta 2), reused 3 (delta 2)\nUnpacking objects: 100% (3/3), done.\n  Fromhttps://github.com/PatrickHeller/core\n   * branch            master     -> FETCH_HEAD\nFirst, rewinding head to replay your work on top of it...\nApplying: distinguish between touch and write\nApplying: remove debug output\n*** Error in `git': malloc(): memory corruption: 0x00000000027f14e0 ***\n\n^C==5995==\n==5995== HEAP SUMMARY:\n==5995==     in use at exit: 1,076 bytes in 11 blocks\n==5995==   total heap usage: 53 allocs, 42 frees, 11,038 bytes allocated\n==5995==\n==5995== LEAK SUMMARY:\n==5995==    definitely lost: 0 bytes in 0 blocks\n==5995==    indirectly lost: 0 bytes in 0 blocks\n==5995==      possibly lost: 0 bytes in 0 blocks\n"},{"id":"210852","messageId":"20130308212831.GA9217@sigill.intra.peff.net","threadId":"33107","inReplyTo":"5139D76D.80703@bernhard-posselt.com","subject":"Re: Memory corruption when rebasing with git version 1.8.1.5 on arch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-08T21:28:31Z","receivedAt":"2013-03-08T21:28:31Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 08, 2013 at 01:19:57PM +0100, Bernhard Posselt wrote:\n\n> Using valgrind gives me:\n> \n> $ valgrind /usr/bin/git pull --rebasehttps://github.com/PatrickHeller/core.git  master\n> ==5995== Memcheck, a memory error detector\n> ==5995== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.\n> ==5995== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info\n> ==5995== Command: /usr/bin/git pull --rebasehttps://github.com/PatrickHeller/core.git  master\n> ==5995==\n> remote: Counting objects: 5, done.\n> remote: Compressing objects: 100% (1/1), done.\n> remote: Total 3 (delta 2), reused 3 (delta 2)\n> Unpacking objects: 100% (3/3), done.\n>  Fromhttps://github.com/PatrickHeller/core\n>   * branch            master     -> FETCH_HEAD\n> First, rewinding head to replay your work on top of it...\n> Applying: distinguish between touch and write\n> Applying: remove debug output\n> *** Error in `git': malloc(): memory corruption: 0x00000000027f14e0 ***\n\nThe problem is likely happening in a sub-command of git-pull, so\nvalgrind isn't reporting it. Can you try re-running with\n\"valgrind --trace-children=yes\", or alternatively narrow down the\nproblematic command by setting GIT_TRACE=1 in the environment?\n\n-Peff\n"},{"id":"210864","messageId":"513A7D80.5000501@bernhard-posselt.com","threadId":"33107","inReplyTo":"20130308212831.GA9217@sigill.intra.peff.net","subject":"Re: Memory corruption when rebasing with git version 1.8.1.5 on arch","fromName":"Bernhard Posselt","fromEmail":"mail@bernhard-posselt.com","sentAt":"2013-03-09T00:08:32Z","receivedAt":"2013-03-09T00:08:32Z","isPatch":false,"sender":{"key":"mail@bernhard-posselt.com","avatar":null},"body":"On 03/08/2013 10:28 PM, Jeff King wrote:\n> On Fri, Mar 08, 2013 at 01:19:57PM +0100, Bernhard Posselt wrote:\n>\n>> Using valgrind gives me:\n>>\n>> $ valgrind /usr/bin/git pull --rebasehttps://github.com/PatrickHeller/core.git  master\n>> ==5995== Memcheck, a memory error detector\n>> ==5995== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.\n>> ==5995== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info\n>> ==5995== Command: /usr/bin/git pull --rebasehttps://github.com/PatrickHeller/core.git  master\n>> ==5995==\n>> remote: Counting objects: 5, done.\n>> remote: Compressing objects: 100% (1/1), done.\n>> remote: Total 3 (delta 2), reused 3 (delta 2)\n>> Unpacking objects: 100% (3/3), done.\n>>   Fromhttps://github.com/PatrickHeller/core\n>>    * branch            master     -> FETCH_HEAD\n>> First, rewinding head to replay your work on top of it...\n>> Applying: distinguish between touch and write\n>> Applying: remove debug output\n>> *** Error in `git': malloc(): memory corruption: 0x00000000027f14e0 ***\n> The problem is likely happening in a sub-command of git-pull, so\n> valgrind isn't reporting it. Can you try re-running with\n> \"valgrind --trace-children=yes\", or alternatively narrow down the\n> problematic command by setting GIT_TRACE=1 in the environment?\n>\n> -Peff\nThanks for the reply!\n\nHeres the output with GIT_TRACE=1, the valgrind log has 4000 lines. If \nyou should still require the valgrind log, please tell me.\n\n$ git pull --rebase https://github.com/PatrickHeller/core.git master\ntrace: exec: 'git-pull' '--rebase' \n'https://github.com/PatrickHeller/core.git' 'master'\ntrace: run_command: 'git-pull' '--rebase' \n'https://github.com/PatrickHeller/core.git' 'master'\ntrace: built-in: git 'rev-parse' '--git-dir'\ntrace: built-in: git 'rev-parse' '--is-bare-repository'\ntrace: built-in: git 'rev-parse' '--show-toplevel'\ntrace: built-in: git 'ls-files' '-u'\ntrace: built-in: git 'symbolic-ref' '-q' 'HEAD'\ntrace: built-in: git 'config' '--bool' 'branch.master.rebase'\ntrace: built-in: git 'config' '--bool' 'pull.rebase'\ntrace: built-in: git 'rev-parse' '-q' '--verify' 'HEAD'\ntrace: built-in: git 'rev-parse' '--verify' 'HEAD'\ntrace: built-in: git 'update-index' '-q' '--ignore-submodules' '--refresh'\ntrace: built-in: git 'diff-files' '--quiet' '--ignore-submodules'\ntrace: built-in: git 'diff-index' '--cached' '--quiet' \n'--ignore-submodules' 'HEAD' '--'\ntrace: built-in: git 'rev-parse' '-q' '--git-dir'\ntrace: built-in: git 'rev-parse' '-q' '--verify' \n'refs/remotes/https://github.com/PatrickHeller/core.git/master'\ntrace: built-in: git 'rev-parse' '-q' '--verify' 'HEAD'\ntrace: built-in: git 'fetch' '--update-head-ok' \n'https://github.com/PatrickHeller/core.git' 'master'\ntrace: run_command: 'git-remote-https' \n'https://github.com/PatrickHeller/core.git' \n'https://github.com/PatrickHeller/core.git'\ntrace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all' \n'--quiet'\ntrace: run_command: 'fetch-pack' '--stateless-rpc' '--stdin' \n'--lock-pack' '--thin' 'https://github.com/PatrickHeller/core.git/'\ntrace: exec: 'git' 'fetch-pack' '--stateless-rpc' '--stdin' \n'--lock-pack' '--thin' 'https://github.com/PatrickHeller/core.git/'\ntrace: built-in: git 'fetch-pack' '--stateless-rpc' '--stdin' \n'--lock-pack' '--thin' 'https://github.com/PatrickHeller/core.git/'\nremote: Counting objects: 5, done.\nremote: Compressing objects: 100% (1/1), done.\nremote: Total 3 (delta 2), reused 3 (delta 2)\ntrace: run_command: 'unpack-objects' '--pack_header=2,3'\ntrace: exec: 'git' 'unpack-objects' '--pack_header=2,3'\ntrace: built-in: git 'unpack-objects' '--pack_header=2,3'\nUnpacking objects: 100% (3/3), done.\ntrace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all'\ntrace: exec: 'git' 'rev-list' '--objects' '--stdin' '--not' '--all'\ntrace: built-in: git 'rev-list' '--objects' '--stdin' '--not' '--all'\n From https://github.com/PatrickHeller/core\n  * branch            master     -> FETCH_HEAD\ntrace: built-in: git 'rev-parse' '-q' '--verify' 'HEAD'\ntrace: built-in: git 'show-branch' '--merge-base' 'refs/heads/master' \n'd686039828089d53fb42e42046d7a9a3992a0507'\ntrace: built-in: git 'fmt-merge-msg'\ntrace: built-in: git 'rev-parse' '--parseopt' '--' '--onto' \n'd686039828089d53fb42e42046d7a9a3992a0507' \n'd686039828089d53fb42e42046d7a9a3992a0507'\ntrace: built-in: git 'rev-parse' '--git-dir'\ntrace: built-in: git 'rev-parse' '--is-bare-repository'\ntrace: built-in: git 'rev-parse' '--show-toplevel'\ntrace: built-in: git 'config' '--bool' 'rebase.stat'\ntrace: built-in: git 'config' '--bool' 'rebase.autosquash'\ntrace: built-in: git 'rev-parse' '--verify' \n'd686039828089d53fb42e42046d7a9a3992a0507^0'\ntrace: built-in: git 'rev-parse' '--verify' \n'd686039828089d53fb42e42046d7a9a3992a0507^0'\ntrace: built-in: git 'symbolic-ref' '-q' 'HEAD'\ntrace: built-in: git 'rev-parse' '--verify' 'master^0'\ntrace: built-in: git 'rev-parse' '--verify' 'HEAD'\ntrace: built-in: git 'update-index' '-q' '--ignore-submodules' '--refresh'\ntrace: built-in: git 'diff-files' '--quiet' '--ignore-submodules'\ntrace: built-in: git 'diff-index' '--cached' '--quiet' \n'--ignore-submodules' 'HEAD' '--'\ntrace: built-in: git 'merge-base' \n'd686039828089d53fb42e42046d7a9a3992a0507' \n'0525bbd73c9015499ba92d1ac654b980aaca35b2'\nFirst, rewinding head to replay your work on top of it...\ntrace: built-in: git 'checkout' '-q' \n'd686039828089d53fb42e42046d7a9a3992a0507^0'\ntrace: built-in: git 'update-ref' 'ORIG_HEAD' \n'0525bbd73c9015499ba92d1ac654b980aaca35b2'\ntrace: exec: 'git-am' '--rebasing' '--resolvemsg=\nWhen you have resolved this problem, run \"git rebase --continue\".\nIf you prefer to skip this patch, run \"git rebase --skip\" instead.\nTo check out the original branch and stop rebasing, run \"git rebase \n--abort\".\n'\ntrace: run_command: 'git-am' '--rebasing' '--resolvemsg=\nWhen you have resolved this problem, run \"git rebase --continue\".\nIf you prefer to skip this patch, run \"git rebase --skip\" instead.\nTo check out the original branch and stop rebasing, run \"git rebase \n--abort\".\n'\ntrace: built-in: git 'format-patch' '-k' '--stdout' '--full-index' \n'--ignore-if-in-upstream' '--src-prefix=a/' '--dst-prefix=b/' \n'--no-renames' \n'd686039828089d53fb42e42046d7a9a3992a0507..0525bbd73c9015499ba92d1ac654b980aaca35b2'\ntrace: built-in: git 'rev-parse' '--parseopt' '--' '--rebasing' \n'--resolvemsg=\nWhen you have resolved this problem, run \"git rebase --continue\".\nIf you prefer to skip this patch, run \"git rebase --skip\" instead.\nTo check out the original branch and stop rebasing, run \"git rebase \n--abort\".\n'\ntrace: built-in: git 'rev-parse' '--git-dir'\ntrace: built-in: git 'rev-parse' '--show-prefix'\ntrace: built-in: git 'rev-parse' '--show-toplevel'\ntrace: built-in: git 'var' 'GIT_COMMITTER_IDENT'\ntrace: built-in: git 'rev-parse' '--verify' '-q' 'HEAD'\ntrace: built-in: git 'config' '--bool' '--get' 'am.keepcr'\ntrace: built-in: git 'mailsplit' '-d4' \n'-o/srv/http/owncloud/.git/rebase-apply' '-b' '--'\ntrace: built-in: git 'update-index' '-q' '--refresh'\ntrace: built-in: git 'diff-index' '--cached' '--name-only' 'HEAD' '--'\ntrace: built-in: git 'cat-file' '-t' \n'48bb53030c657e1133da47765c7c778a069af665'\ntrace: built-in: git 'cat-file' 'commit' \n'48bb53030c657e1133da47765c7c778a069af665'\ntrace: built-in: git 'config' 'i18n.commitencoding'\ntrace: built-in: git 'show' '-s' '--pretty=raw' '--encoding=UTF-8' \n'48bb53030c657e1133da47765c7c778a069af665' '--'\ntrace: built-in: git 'diff-tree' '--root' '--binary' '--full-index' \n'48bb53030c657e1133da47765c7c778a069af665'\nApplying: distinguish between touch and write\ntrace: built-in: git 'write-tree'\ntrace: built-in: git 'rev-parse' '--verify' '-q' 'HEAD'\ntrace: built-in: git 'commit-tree' \n'd785d568d8b4649dfdcc01e03d6c8e87b036ea5a' '-p' \n'd686039828089d53fb42e42046d7a9a3992a0507'\ntrace: built-in: git 'update-ref' '-m' 'pull --rebase \nhttps://github.com/PatrickHeller/core.git master: distinguish between \ntouch and write' 'HEAD' '2726978d8cbd9b0a3367fd3d62b64b4c78438e79'\ntrace: built-in: git 'cat-file' '-t' \n'45869afa5ac718e11c3d2e3bccdb501a022cfc24'\ntrace: built-in: git 'cat-file' 'commit' \n'45869afa5ac718e11c3d2e3bccdb501a022cfc24'\ntrace: built-in: git 'config' 'i18n.commitencoding'\ntrace: built-in: git 'show' '-s' '--pretty=raw' '--encoding=UTF-8' \n'45869afa5ac718e11c3d2e3bccdb501a022cfc24' '--'\ntrace: built-in: git 'diff-tree' '--root' '--binary' '--full-index' \n'45869afa5ac718e11c3d2e3bccdb501a022cfc24'\nApplying: remove debug output\n*** Error in `git': malloc(): memory corruption: 0x000000000139f4e0 ***\n"},{"id":"210870","messageId":"20130309044850.GB12167@sigill.intra.peff.net","threadId":"33107","inReplyTo":"513A7D80.5000501@bernhard-posselt.com","subject":"Re: Memory corruption when rebasing with git version 1.8.1.5 on arch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-09T04:48:50Z","receivedAt":"2013-03-09T04:48:50Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Mar 09, 2013 at 01:08:32AM +0100, Bernhard Posselt wrote:\n\n> >The problem is likely happening in a sub-command of git-pull, so\n> >valgrind isn't reporting it. Can you try re-running with\n> >\"valgrind --trace-children=yes\", or alternatively narrow down the\n> >problematic command by setting GIT_TRACE=1 in the environment?\n>\n> Heres the output with GIT_TRACE=1, the valgrind log has 4000 lines.\n> If you should still require the valgrind log, please tell me.\n\nHmm, the GIT_TRACE output was less clear than I had hoped; it's unclear\nto me which git program is actually dying (my guess is \"git apply\", and\nwe are squelching stderr, which is where the GIT_TRACE output is going).\n\nCan you try it once again with something like GIT_TRACE=/tmp/foo.out,\nwhich will make sure we record the trace directly, even if stderr ends\nup redirected?\n\nAlso, I can almost reproduce here, as PatrickHeller/core.git is public.\nHowever, I suspect the problem is particular to your work built on top,\nwhich looks like it is at commit 0525bbd73c9015499ba92d1ac654b980aaca35b2.\nIs it possible for you to make that commit available on a temporary\nbranch?\n\n-Peff\n"},{"id":"210889","messageId":"513B14EC.4040504@bernhard-posselt.com","threadId":"33107","inReplyTo":"20130309044850.GB12167@sigill.intra.peff.net","subject":"Re: Memory corruption when rebasing with git version 1.8.1.5 on arch","fromName":"Bernhard Posselt","fromEmail":"mail@bernhard-posselt.com","sentAt":"2013-03-09T10:54:36Z","receivedAt":"2013-03-09T10:54:36Z","isPatch":false,"sender":{"key":"mail@bernhard-posselt.com","avatar":null},"body":"On 03/09/2013 05:48 AM, Jeff King wrote:\n> On Sat, Mar 09, 2013 at 01:08:32AM +0100, Bernhard Posselt wrote:\n>\n>>> The problem is likely happening in a sub-command of git-pull, so\n>>> valgrind isn't reporting it. Can you try re-running with\n>>> \"valgrind --trace-children=yes\", or alternatively narrow down the\n>>> problematic command by setting GIT_TRACE=1 in the environment?\n>> Heres the output with GIT_TRACE=1, the valgrind log has 4000 lines.\n>> If you should still require the valgrind log, please tell me.\n> Hmm, the GIT_TRACE output was less clear than I had hoped; it's unclear\n> to me which git program is actually dying (my guess is \"git apply\", and\n> we are squelching stderr, which is where the GIT_TRACE output is going).\n>\n> Can you try it once again with something like GIT_TRACE=/tmp/foo.out,\n> which will make sure we record the trace directly, even if stderr ends\n> up redirected?\n>\n> Also, I can almost reproduce here, as PatrickHeller/core.git is public.\n> However, I suspect the problem is particular to your work built on top,\n> which looks like it is at commit 0525bbd73c9015499ba92d1ac654b980aaca35b2.\n> Is it possible for you to make that commit available on a temporary\n> branch?\n>\n> -Peff\n > commit available on a temporary branch?\nWhat do you mean exactly by that?\n\nI've made copies of both repositories on github.\n\nHeres a copy of the basic repo: \nhttps://github.com/Raydiation/memorycorruption\nHeres my clone of the repo that i pull from: \nhttps://github.com/Raydiation/core\n\nBasically:\n\ngit clone https://github.com/Raydiation/memorycorruption\ncd memorycorruption\ngit pull --rebase https://github.com/Raydiation/core\n\nHeres the output of the GIT_TRACE file\n\ntrace: built-in: git 'branch'\ntrace: built-in: git 'branch' '--no-color'\ntrace: built-in: git 'status'\ntrace: exec: 'git-pull' '--rebase' 'https://github.com/Raydiation/core' \n'master'\ntrace: run_command: 'git-pull' '--rebase' \n'https://github.com/Raydiation/core' 'master'\ntrace: built-in: git 'rev-parse' '--git-dir'\ntrace: built-in: git 'rev-parse' '--is-bare-repository'\ntrace: built-in: git 'rev-parse' '--show-toplevel'\ntrace: built-in: git 'ls-files' '-u'\ntrace: built-in: git 'symbolic-ref' '-q' 'HEAD'\ntrace: built-in: git 'config' '--bool' 'branch.master.rebase'\ntrace: built-in: git 'config' '--bool' 'pull.rebase'\ntrace: built-in: git 'rev-parse' '-q' '--verify' 'HEAD'\ntrace: built-in: git 'rev-parse' '--verify' 'HEAD'\ntrace: built-in: git 'update-index' '-q' '--ignore-submodules' '--refresh'\ntrace: built-in: git 'diff-files' '--quiet' '--ignore-submodules'\ntrace: built-in: git 'diff-index' '--cached' '--quiet' \n'--ignore-submodules' 'HEAD' '--'\ntrace: built-in: git 'rev-parse' '-q' '--git-dir'\ntrace: built-in: git 'rev-parse' '-q' '--verify' \n'refs/remotes/https://github.com/Raydiation/core/master'\ntrace: built-in: git 'rev-parse' '-q' '--verify' 'HEAD'\ntrace: built-in: git 'fetch' '--update-head-ok' \n'https://github.com/Raydiation/core' 'master'\ntrace: run_command: 'git-remote-https' \n'https://github.com/Raydiation/core' 'https://github.com/Raydiation/core'\ntrace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all' \n'--quiet'\ntrace: exec: 'git' 'rev-list' '--objects' '--stdin' '--not' '--all' \n'--quiet'\ntrace: built-in: git 'rev-list' '--objects' '--stdin' '--not' '--all' \n'--quiet'\ntrace: run_command: 'fetch-pack' '--stateless-rpc' '--stdin' \n'--lock-pack' '--thin' 'https://github.com/Raydiation/core/'\ntrace: exec: 'git' 'fetch-pack' '--stateless-rpc' '--stdin' \n'--lock-pack' '--thin' 'https://github.com/Raydiation/core/'\ntrace: built-in: git 'fetch-pack' '--stateless-rpc' '--stdin' \n'--lock-pack' '--thin' 'https://github.com/Raydiation/core/'\ntrace: run_command: 'unpack-objects' '--pack_header=2,3'\ntrace: exec: 'git' 'unpack-objects' '--pack_header=2,3'\ntrace: built-in: git 'unpack-objects' '--pack_header=2,3'\ntrace: run_command: 'rev-list' '--objects' '--stdin' '--not' '--all'\ntrace: exec: 'git' 'rev-list' '--objects' '--stdin' '--not' '--all'\ntrace: built-in: git 'rev-list' '--objects' '--stdin' '--not' '--all'\ntrace: built-in: git 'rev-parse' '-q' '--verify' 'HEAD'\ntrace: built-in: git 'show-branch' '--merge-base' 'refs/heads/master' \n'd686039828089d53fb42e42046d7a9a3992a0507'\ntrace: built-in: git 'fmt-merge-msg'\ntrace: built-in: git 'rev-parse' '--parseopt' '--' '--onto' \n'd686039828089d53fb42e42046d7a9a3992a0507' \n'd686039828089d53fb42e42046d7a9a3992a0507'\ntrace: built-in: git 'rev-parse' '--git-dir'\ntrace: built-in: git 'rev-parse' '--is-bare-repository'\ntrace: built-in: git 'rev-parse' '--show-toplevel'\ntrace: built-in: git 'config' '--bool' 'rebase.stat'\ntrace: built-in: git 'config' '--bool' 'rebase.autosquash'\ntrace: built-in: git 'rev-parse' '--verify' \n'd686039828089d53fb42e42046d7a9a3992a0507^0'\ntrace: built-in: git 'rev-parse' '--verify' \n'd686039828089d53fb42e42046d7a9a3992a0507^0'\ntrace: built-in: git 'symbolic-ref' '-q' 'HEAD'\ntrace: built-in: git 'rev-parse' '--verify' 'master^0'\ntrace: built-in: git 'rev-parse' '--verify' 'HEAD'\ntrace: built-in: git 'update-index' '-q' '--ignore-submodules' '--refresh'\ntrace: built-in: git 'diff-files' '--quiet' '--ignore-submodules'\ntrace: built-in: git 'diff-index' '--cached' '--quiet' \n'--ignore-submodules' 'HEAD' '--'\ntrace: built-in: git 'merge-base' \n'd686039828089d53fb42e42046d7a9a3992a0507' \n'0525bbd73c9015499ba92d1ac654b980aaca35b2'\ntrace: built-in: git 'checkout' '-q' \n'd686039828089d53fb42e42046d7a9a3992a0507^0'\ntrace: built-in: git 'update-ref' 'ORIG_HEAD' \n'0525bbd73c9015499ba92d1ac654b980aaca35b2'\ntrace: built-in: git 'format-patch' '-k' '--stdout' '--full-index' \n'--ignore-if-in-upstream' '--src-prefix=a/' '--dst-prefix=b/' \n'--no-renames' \n'd686039828089d53fb42e42046d7a9a3992a0507..0525bbd73c9015499ba92d1ac654b980aaca35b2'\ntrace: exec: 'git-am' '--rebasing' '--resolvemsg=\nWhen you have resolved this problem, run \"git rebase --continue\".\nIf you prefer to skip this patch, run \"git rebase --skip\" instead.\nTo check out the original branch and stop rebasing, run \"git rebase \n--abort\".\n'\ntrace: run_command: 'git-am' '--rebasing' '--resolvemsg=\nWhen you have resolved this problem, run \"git rebase --continue\".\nIf you prefer to skip this patch, run \"git rebase --skip\" instead.\nTo check out the original branch and stop rebasing, run \"git rebase \n--abort\".\n'\ntrace: built-in: git 'rev-parse' '--parseopt' '--' '--rebasing' \n'--resolvemsg=\nWhen you have resolved this problem, run \"git rebase --continue\".\nIf you prefer to skip this patch, run \"git rebase --skip\" instead.\nTo check out the original branch and stop rebasing, run \"git rebase \n--abort\".\n'\ntrace: built-in: git 'rev-parse' '--git-dir'\ntrace: built-in: git 'rev-parse' '--show-prefix'\ntrace: built-in: git 'rev-parse' '--is-inside-work-tree'\ntrace: built-in: git 'rev-parse' '--show-toplevel'\ntrace: built-in: git 'var' 'GIT_COMMITTER_IDENT'\ntrace: built-in: git 'rev-parse' '--verify' '-q' 'HEAD'\ntrace: built-in: git 'config' '--bool' '--get' 'am.keepcr'\ntrace: built-in: git 'mailsplit' '-d4' \n'-o/srv/http/owncloud/.git/rebase-apply' '-b' '--'\ntrace: built-in: git 'update-index' '-q' '--refresh'\ntrace: built-in: git 'diff-index' '--cached' '--name-only' 'HEAD' '--'\ntrace: built-in: git 'cat-file' '-t' \n'48bb53030c657e1133da47765c7c778a069af665'\ntrace: built-in: git 'cat-file' 'commit' \n'48bb53030c657e1133da47765c7c778a069af665'\ntrace: built-in: git 'config' 'i18n.commitencoding'\ntrace: built-in: git 'show' '-s' '--pretty=raw' '--encoding=UTF-8' \n'48bb53030c657e1133da47765c7c778a069af665' '--'\ntrace: built-in: git 'diff-tree' '--root' '--binary' '--full-index' \n'48bb53030c657e1133da47765c7c778a069af665'\ntrace: built-in: git 'apply' '--index' \n'/srv/http/owncloud/.git/rebase-apply/patch'\ntrace: built-in: git 'write-tree'\ntrace: built-in: git 'rev-parse' '--verify' '-q' 'HEAD'\ntrace: built-in: git 'commit-tree' \n'd785d568d8b4649dfdcc01e03d6c8e87b036ea5a' '-p' \n'd686039828089d53fb42e42046d7a9a3992a0507'\ntrace: built-in: git 'update-ref' '-m' 'pull --rebase \nhttps://github.com/Raydiation/core master: distinguish between touch and \nwrite' 'HEAD' '3b7aa1e847993b2afdbaf19cd8ed50b81d37fc5b'\ntrace: built-in: git 'cat-file' '-t' \n'45869afa5ac718e11c3d2e3bccdb501a022cfc24'\ntrace: built-in: git 'cat-file' 'commit' \n'45869afa5ac718e11c3d2e3bccdb501a022cfc24'\ntrace: built-in: git 'config' 'i18n.commitencoding'\ntrace: built-in: git 'show' '-s' '--pretty=raw' '--encoding=UTF-8' \n'45869afa5ac718e11c3d2e3bccdb501a022cfc24' '--'\ntrace: built-in: git 'diff-tree' '--root' '--binary' '--full-index' \n'45869afa5ac718e11c3d2e3bccdb501a022cfc24'\ntrace: built-in: git 'apply' '--index' \n'/srv/http/owncloud/.git/rebase-apply/patch'\n"},{"id":"210958","messageId":"20130310070505.GA15324@sigill.intra.peff.net","threadId":"33107","inReplyTo":"513B14EC.4040504@bernhard-posselt.com","subject":"Re: Memory corruption when rebasing with git version 1.8.1.5 on arch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-10T07:05:05Z","receivedAt":"2013-03-10T07:05:05Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Mar 09, 2013 at 11:54:36AM +0100, Bernhard Posselt wrote:\n\n> >Also, I can almost reproduce here, as PatrickHeller/core.git is public.\n> >However, I suspect the problem is particular to your work built on top,\n> >which looks like it is at commit 0525bbd73c9015499ba92d1ac654b980aaca35b2.\n> >Is it possible for you to make that commit available on a temporary\n> >branch?\n\n> What do you mean exactly by that?\n\nI just meant to push the work from your local repository somewhere where\nI could access it to try to replicate the issue. What you did here:\n\n> git clone https://github.com/Raydiation/memorycorruption\n> cd memorycorruption\n> git pull --rebase https://github.com/Raydiation/core\n\n...should be plenty. Unfortunately, I'm not able to reproduce the\nsegfault.  All of the patches apply fine, both normally and when run\nunder valgrind.\n\n> Heres the output of the GIT_TRACE file\n> [...]\n> trace: built-in: git 'apply' '--index' '/srv/http/owncloud/.git/rebase-apply/patch'\n\nThis confirms my suspicion that the problem is in \"git apply\".\n\nYou had mentioned before that the valgrind log was very long.  If you're\nstill able to reproduce, could you try running it with valgrind like\nthis:\n\n  valgrind -q --trace-children=yes --log-file=/tmp/valgrind.out \\\n    git pull --rebase https://github.com/Raydiation/core\n\nLogging to a file instead of stderr should mean we still get output for\ncommands that are invoked with their stderr redirected (which is the\ncase for the \"git apply\" in question), and using \"-q\" should eliminate\nthe uninteresting cruft from the log.\n\n-Peff\n"},{"id":"210968","messageId":"513C68DA.8060700@bernhard-posselt.com","threadId":"33107","inReplyTo":"20130310070505.GA15324@sigill.intra.peff.net","subject":"Re: Memory corruption when rebasing with git version 1.8.1.5 on arch","fromName":"Bernhard Posselt","fromEmail":"mail@bernhard-posselt.com","sentAt":"2013-03-10T11:04:58Z","receivedAt":"2013-03-10T11:04:58Z","isPatch":false,"sender":{"key":"mail@bernhard-posselt.com","avatar":null},"body":"On 03/10/2013 08:05 AM, Jeff King wrote:\n> On Sat, Mar 09, 2013 at 11:54:36AM +0100, Bernhard Posselt wrote:\n>\n>>> Also, I can almost reproduce here, as PatrickHeller/core.git is public.\n>>> However, I suspect the problem is particular to your work built on top,\n>>> which looks like it is at commit 0525bbd73c9015499ba92d1ac654b980aaca35b2.\n>>> Is it possible for you to make that commit available on a temporary\n>>> branch?\n>> What do you mean exactly by that?\n> I just meant to push the work from your local repository somewhere where\n> I could access it to try to replicate the issue. What you did here:\n>\n>> git clone https://github.com/Raydiation/memorycorruption\n>> cd memorycorruption\n>> git pull --rebase https://github.com/Raydiation/core\n> ...should be plenty. Unfortunately, I'm not able to reproduce the\n> segfault.  All of the patches apply fine, both normally and when run\n> under valgrind.\n>\n>> Heres the output of the GIT_TRACE file\n>> [...]\n>> trace: built-in: git 'apply' '--index' '/srv/http/owncloud/.git/rebase-apply/patch'\n> This confirms my suspicion that the problem is in \"git apply\".\n>\n> You had mentioned before that the valgrind log was very long.  If you're\n> still able to reproduce, could you try running it with valgrind like\n> this:\n>\n>    valgrind -q --trace-children=yes --log-file=/tmp/valgrind.out \\\n>      git pull --rebase https://github.com/Raydiation/core\n>\n> Logging to a file instead of stderr should mean we still get output for\n> commands that are invoked with their stderr redirected (which is the\n> case for the \"git apply\" in question), and using \"-q\" should eliminate\n> the uninteresting cruft from the log.\n>\n> -Peff\nDo you need debug symbols?\n\n==2395== Invalid write of size 1\n==2395==    at 0x4C2DB93: memcpy@@GLIBC_2.14 (in \n/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)\n==2395==    by 0x4076B1: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x40A60F: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x40C29F: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x40CC35: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x40F584: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x4058E7: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x404DD1: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x58F3A14: (below main) (in /usr/lib/libc-2.17.so)\n==2395==  Address 0x5f245c0 is 0 bytes after a block of size 384 alloc'd\n==2395==    at 0x4C2C04B: malloc (in \n/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)\n==2395==    by 0x4C2C2FF: realloc (in \n/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)\n==2395==    by 0x4F057B: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x4DDF9F: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x409E9C: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x40C29F: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x40CC35: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x40F584: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x4058E7: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x404DD1: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x58F3A14: (below main) (in /usr/lib/libc-2.17.so)\n==2395==\n==2395== Invalid read of size 1\n==2395==    at 0x4C2DCB4: memcpy@@GLIBC_2.14 (in \n/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)\n==2395==    by 0x40B0D5: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x40C29F: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x40CC35: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x40F584: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x4058E7: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x404DD1: ??? (in /usr/lib/git-core/git)\n==2395==    by 0x58F3A14: (below main) (in /usr/lib/libc-2.17.so)\n==2395==  Address 0x5f245e1 is not stack'd, malloc'd or (recently) free'd\n==2395==\n"},{"id":"210971","messageId":"513C7267.2090608@bernhard-posselt.com","threadId":"33107","inReplyTo":"20130310070505.GA15324@sigill.intra.peff.net","subject":"Re: Memory corruption when rebasing with git version 1.8.1.5 on arch","fromName":"Bernhard Posselt","fromEmail":"mail@bernhard-posselt.com","sentAt":"2013-03-10T11:45:43Z","receivedAt":"2013-03-10T11:45:43Z","isPatch":false,"sender":{"key":"mail@bernhard-posselt.com","avatar":null},"body":"On 03/10/2013 08:05 AM, Jeff King wrote:\n> On Sat, Mar 09, 2013 at 11:54:36AM +0100, Bernhard Posselt wrote:\n>\n>>> Also, I can almost reproduce here, as PatrickHeller/core.git is public.\n>>> However, I suspect the problem is particular to your work built on top,\n>>> which looks like it is at commit 0525bbd73c9015499ba92d1ac654b980aaca35b2.\n>>> Is it possible for you to make that commit available on a temporary\n>>> branch?\n>> What do you mean exactly by that?\n> I just meant to push the work from your local repository somewhere where\n> I could access it to try to replicate the issue. What you did here:\n>\n>> git clone https://github.com/Raydiation/memorycorruption\n>> cd memorycorruption\n>> git pull --rebase https://github.com/Raydiation/core\n> ...should be plenty. Unfortunately, I'm not able to reproduce the\n> segfault.  All of the patches apply fine, both normally and when run\n> under valgrind.\n>\n>> Heres the output of the GIT_TRACE file\n>> [...]\n>> trace: built-in: git 'apply' '--index' '/srv/http/owncloud/.git/rebase-apply/patch'\n> This confirms my suspicion that the problem is in \"git apply\".\n>\n> You had mentioned before that the valgrind log was very long.  If you're\n> still able to reproduce, could you try running it with valgrind like\n> this:\n>\n>    valgrind -q --trace-children=yes --log-file=/tmp/valgrind.out \\\n>      git pull --rebase https://github.com/Raydiation/core\n>\n> Logging to a file instead of stderr should mean we still get output for\n> commands that are invoked with their stderr redirected (which is the\n> case for the \"git apply\" in question), and using \"-q\" should eliminate\n> the uninteresting cruft from the log.\n>\n> -Peff\nFirst time I've used Archlinux ABS and build from source :)\n\nThe log file was empty and it seemed to apply everything nice when \nrunning valgrind. When i tried to run it without valgrind it failed with \nmemory corruption.\nHeres the output with debug symbols, fetched with tail -f:\n\n==22291== Invalid write of size 1\n==22291==    at 0x4C2DB93: memcpy@@GLIBC_2.14 (in \n/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)\n==22291==    by 0x4076B1: update_pre_post_images (in /usr/lib/git-core/git)\n==22291==    by 0x40A60F: apply_fragments (in /usr/lib/git-core/git)\n==22291==    by 0x40C29F: check_patch_list (in /usr/lib/git-core/git)\n==22291==    by 0x40CC35: apply_patch (in /usr/lib/git-core/git)\n==22291==    by 0x40F584: cmd_apply (in /usr/lib/git-core/git)\n==22291==    by 0x4058E7: handle_internal_command (in /usr/lib/git-core/git)\n==22291==    by 0x404DD1: main (in /usr/lib/git-core/git)\n==22291==  Address 0x5f245c0 is 0 bytes after a block of size 384 alloc'd\n==22291==    at 0x4C2C04B: malloc (in \n/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)\n==22291==    by 0x4C2C2FF: realloc (in \n/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)\n==22291==    by 0x4F057B: xrealloc (in /usr/lib/git-core/git)\n==22291==    by 0x4DDF9F: strbuf_grow (in /usr/lib/git-core/git)\n==22291==    by 0x409E9C: apply_fragments (in /usr/lib/git-core/git)\n==22291==    by 0x40C29F: check_patch_list (in /usr/lib/git-core/git)\n==22291==    by 0x40CC35: apply_patch (in /usr/lib/git-core/git)\n==22291==    by 0x40F584: cmd_apply (in /usr/lib/git-core/git)\n==22291==    by 0x4058E7: handle_internal_command (in /usr/lib/git-core/git)\n==22291==    by 0x404DD1: main (in /usr/lib/git-core/git)\n==22291==\n==22291== Invalid read of size 1\n==22291==    at 0x4C2DCB4: memcpy@@GLIBC_2.14 (in \n/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)\n==22291==    by 0x40B0D5: apply_fragments (in /usr/lib/git-core/git)\n==22291==    by 0x40C29F: check_patch_list (in /usr/lib/git-core/git)\n==22291==    by 0x40CC35: apply_patch (in /usr/lib/git-core/git)\n==22291==    by 0x40F584: cmd_apply (in /usr/lib/git-core/git)\n==22291==    by 0x4058E7: handle_internal_command (in /usr/lib/git-core/git)\n==22291==    by 0x404DD1: main (in /usr/lib/git-core/git)\n==22291==  Address 0x5f245e1 is not stack'd, malloc'd or (recently) free'd\n==22291==\n"},{"id":"211023","messageId":"20130311051840.GB13510@sigill.intra.peff.net","threadId":"33107","inReplyTo":"513C7267.2090608@bernhard-posselt.com","subject":"Re: Memory corruption when rebasing with git version 1.8.1.5 on arch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-11T05:18:41Z","receivedAt":"2013-03-11T05:18:41Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Mar 10, 2013 at 12:45:43PM +0100, Bernhard Posselt wrote:\n\n> >   valgrind -q --trace-children=yes --log-file=/tmp/valgrind.out \\\n> >     git pull --rebase https://github.com/Raydiation/core\n> \n> The log file was empty and it seemed to apply everything nice when\n> running valgrind. When i tried to run it without valgrind it failed\n> with memory corruption.\n\nThanks, we are maybe getting closer. It's weird that it works OK with\nvalgrind. If the valgrind log is empty, though, I'm confused about where\nthe output you pasted below came from.\n\n> ==22291== Invalid write of size 1\n> ==22291==    at 0x4C2DB93: memcpy@@GLIBC_2.14 (in\n> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)\n> ==22291==    by 0x4076B1: update_pre_post_images (in /usr/lib/git-core/git)\n> ==22291==    by 0x40A60F: apply_fragments (in /usr/lib/git-core/git)\n> ==22291==    by 0x40C29F: check_patch_list (in /usr/lib/git-core/git)\n> ==22291==    by 0x40CC35: apply_patch (in /usr/lib/git-core/git)\n> ==22291==    by 0x40F584: cmd_apply (in /usr/lib/git-core/git)\n> ==22291==    by 0x4058E7: handle_internal_command (in /usr/lib/git-core/git)\n> ==22291==    by 0x404DD1: main (in /usr/lib/git-core/git)\n\nHmm, it would be nice to have line numbers. Can you try compiling with\n\"-g -O0\"?\n\nThe function where the problem is deals with whitespace munging. Just a\nguess, but do you have any whitespace config options set (e.g.,\napply.whitespace)?\n\n-Peff\n"},{"id":"211653","messageId":"51484125.9000307@bernhard-posselt.com","threadId":"33107","inReplyTo":"20130311051840.GB13510@sigill.intra.peff.net","subject":"Re: Memory corruption when rebasing with git version 1.8.1.5 on arch","fromName":"Bernhard Posselt","fromEmail":"mail@bernhard-posselt.com","sentAt":"2013-03-19T10:42:45Z","receivedAt":"2013-03-19T10:42:45Z","isPatch":false,"sender":{"key":"mail@bernhard-posselt.com","avatar":null},"body":"Ok, sorrry for not responsding for quite a while, we had the 5.0 release and had too much to do.\n\nI found out why it segfaults: I had a .gitconfig file (sry must have somehow missed that no idea why actually) with the following contents:\n\nhttp://dpaste.com/1027662/\n\nit seems that the memory corruption does not happen anymore when i change\n\n[apply]\n         whitespace = fix\n\nto\n\n[apply]\n         #whitespace = fix\n\n\nso fixing whitespaces may be the culprit\n\nOn 03/11/2013 06:18 AM, Jeff King wrote:\n> On Sun, Mar 10, 2013 at 12:45:43PM +0100, Bernhard Posselt wrote:\n>\n>>>    valgrind -q --trace-children=yes --log-file=/tmp/valgrind.out \\\n>>>      git pull --rebase https://github.com/Raydiation/core\n>> The log file was empty and it seemed to apply everything nice when\n>> running valgrind. When i tried to run it without valgrind it failed\n>> with memory corruption.\n> Thanks, we are maybe getting closer. It's weird that it works OK with\n> valgrind. If the valgrind log is empty, though, I'm confused about where\n> the output you pasted below came from.\n>\n>> ==22291== Invalid write of size 1\n>> ==22291==    at 0x4C2DB93: memcpy@@GLIBC_2.14 (in\n>> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)\n>> ==22291==    by 0x4076B1: update_pre_post_images (in /usr/lib/git-core/git)\n>> ==22291==    by 0x40A60F: apply_fragments (in /usr/lib/git-core/git)\n>> ==22291==    by 0x40C29F: check_patch_list (in /usr/lib/git-core/git)\n>> ==22291==    by 0x40CC35: apply_patch (in /usr/lib/git-core/git)\n>> ==22291==    by 0x40F584: cmd_apply (in /usr/lib/git-core/git)\n>> ==22291==    by 0x4058E7: handle_internal_command (in /usr/lib/git-core/git)\n>> ==22291==    by 0x404DD1: main (in /usr/lib/git-core/git)\n> Hmm, it would be nice to have line numbers. Can you try compiling with\n> \"-g -O0\"?\n>\n> The function where the problem is deals with whitespace munging. Just a\n> guess, but do you have any whitespace config options set (e.g.,\n> apply.whitespace)?\n>\n> -Peff\n"},{"id":"211667","messageId":"20130319134452.GA6752@sigill.intra.peff.net","threadId":"33107","inReplyTo":"51484125.9000307@bernhard-posselt.com","subject":"Re: Memory corruption when rebasing with git version 1.8.1.5 on arch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-19T13:44:52Z","receivedAt":"2013-03-19T13:44:52Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Mar 19, 2013 at 11:42:45AM +0100, Bernhard Posselt wrote:\n\n> it seems that the memory corruption does not happen anymore when i change\n> \n> [apply]\n>         whitespace = fix\n> \n> to\n> \n> [apply]\n>         #whitespace = fix\n> \n> so fixing whitespaces may be the culprit\n\nThanks, I'm able to reproduce with the config you showed. The other key\nelement seems to be using tab-in-indent.  I am not too familiar with\nthis code, but I was able to get a much smaller reproduction recipe:\n\n-- >8 --\n# make tabs more obvious by using \"Q\" instead\nq_to_tab() {\n  perl -lpe 's/Q/\\t/g'\n}\n\nq_to_tab >preimage <<\\EOF\nQQa\nQQb\nQQc\n                d\nQQe\nQQf\nQQg\nEOF\n\nq_to_tab >patch <<\\EOF\ndiff --git a/preimage b/preimage\n--- a/preimage\n+++ b/preimage\n@@ -1,7 +1,6 @@ public static function store($filename) {\n QQa\n QQb\n QQc\n-QQd\n QQe\n QQf\n QQg\nEOF\n\nvalgrind \\\ngit -c core.whitespace=tab-in-indent apply --whitespace=fix patch\n-- 8< --\n\nwhich yields:\n\n==7112== Invalid write of size 2\n==7112==    at 0x4C2C023: memcpy (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)\n==7112==    by 0x40C365: update_pre_post_images (apply.c:2165)\n==7112==    by 0x40CC52: match_fragment (apply.c:2402)\n[...]\n==7112==  Address 0x6e57a5e is 0 bytes after a block of size 94 alloc'd\n==7112==    at 0x4C2A26B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)\n==7112==    by 0x4C2A51F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)\n==7112==    by 0x535193: xrealloc (wrapper.c:100)\n==7112==    by 0x51C322: strbuf_grow (strbuf.c:74)\n==7112==    by 0x51C10C: strbuf_init (strbuf.c:34)\n==7112==    by 0x40D329: apply_one_fragment (apply.c:2602)\n[...]\n\nand so on. I haven't quite figured out what is going on. It looks like\nwe call update_pre_post_images with postlen==0, which causes it to just\nwrite the fixed postimage into the existing buffer. But of course the\nfixed version is bigger, because we are expanding the tabs into 8\nspaces (but it _doesn't_ break if each line starts with only one tab,\nwhich confuses me).\n\nI'm not too familiar with this code. Maybe Junio can say more.\n\n-Peff\n"},{"id":"211687","messageId":"7vobefjs26.fsf@alter.siamese.dyndns.org","threadId":"33107","inReplyTo":"20130319134452.GA6752@sigill.intra.peff.net","subject":"Re: Memory corruption when rebasing with git version 1.8.1.5 on arch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-19T16:02:57Z","receivedAt":"2013-03-19T16:02:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King <peff@peff.net> writes:\n\n> and so on. I haven't quite figured out what is going on. It looks like\n> we call update_pre_post_images with postlen==0, which causes it to just\n> write the fixed postimage into the existing buffer. But of course the\n> fixed version is bigger, because we are expanding the tabs into 8\n> spaces (but it _doesn't_ break if each line starts with only one tab,\n> which confuses me).\n\nI used to be intimately familiar with the update_pre_post_images()\nfunction, but the version after 86c91f91794c (git apply: option to\nignore whitespace differences, 2009-08-04), I won't vouch for it\ndoing anything sensible.  We recently had to do 5de7166d46d2\n(apply.c:update_pre_post_images(): the preimage can be truncated,\n2012-10-12) to fix one of its corner cases but I would not be\nsurprised if there are other cases the function gets it all wrong.\n\nI'd come back to the topic after I finish other tasks on my plate,\nso if somebody is inclined please go ahead digging this a bit\nfurther; I won't have much head start to begin with in this code\nX-<.\n"},{"id":"211966","messageId":"7vip4j71dw.fsf@alter.siamese.dyndns.org","threadId":"33107","inReplyTo":"7vobefjs26.fsf@alter.siamese.dyndns.org","subject":"Re: Memory corruption when rebasing with git version 1.8.1.5 on arch","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-03-22T18:08:59Z","receivedAt":"2013-03-22T18:08:59Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Jeff King <peff@peff.net> writes:\n>\n>> and so on. I haven't quite figured out what is going on. It looks like\n>> we call update_pre_post_images with postlen==0, which causes it to just\n>> write the fixed postimage into the existing buffer. But of course the\n>> fixed version is bigger, because we are expanding the tabs into 8\n>> spaces (but it _doesn't_ break if each line starts with only one tab,\n>> which confuses me).\n>\n> I used to be intimately familiar with the update_pre_post_images()\n> function, but the version after 86c91f91794c (git apply: option to\n> ignore whitespace differences, 2009-08-04), I won't vouch for it\n> doing anything sensible.  We recently had to do 5de7166d46d2\n> (apply.c:update_pre_post_images(): the preimage can be truncated,\n> 2012-10-12) to fix one of its corner cases but I would not be\n> surprised if there are other cases the function gets it all wrong.\n>\n> I'd come back to the topic after I finish other tasks on my plate,\n> so if somebody is inclined please go ahead digging this a bit\n> further; I won't have much head start to begin with in this code\n> X-<.\n\nThis may be sufficient.  In the olden days, we relied on that all\nwhitespace fixing rules made the result shorter and took advantage\nof it in update-pre-post-images to rewrite the images in place.  The\noddball tab-in-indent (aka Python), however, can grow the result by\nexpanding tabs (deemed \"incorrect\") in the input into runs of spaces\n(deemed \"kosher\").\n\nFortunately, we already support its more generalized form \"match\nwhile ignoring whitespace differences\" that can lengthen the result;\nas long as we correctly count the number of bytes needed to hold\nrewritten postimage, the existing logic in update_pre_post_images\nshould be able to do the rest for us.\n\n builtin/apply.c          | 16 ++++++++++------\n t/t4124-apply-ws-rule.sh | 26 ++++++++++++++++++++++++++\n t/t4150-am.sh            |  2 +-\n t/test-lib-functions.sh  |  4 ++--\n 4 files changed, 39 insertions(+), 9 deletions(-)\n\ndiff --git a/builtin/apply.c b/builtin/apply.c\nindex 080ce2e..cad4e4f 100644\n--- a/builtin/apply.c\n+++ b/builtin/apply.c\n@@ -2117,10 +2117,10 @@ static void update_pre_post_images(struct image *preimage,\n \n \t/*\n \t * Adjust the common context lines in postimage. This can be\n-\t * done in-place when we are just doing whitespace fixing,\n-\t * which does not make the string grow, but needs a new buffer\n-\t * when ignoring whitespace causes the update, since in this case\n-\t * we could have e.g. tabs converted to multiple spaces.\n+\t * done in-place when we are shrinking it with whitespace\n+\t * fixing, but needs a new buffer when ignoring whitespace or\n+\t * expanding leading tabs to spaces.\n+\t *\n \t * We trust the caller to tell us if the update can be done\n \t * in place (postlen==0) or not.\n \t */\n@@ -2185,7 +2185,7 @@ static int match_fragment(struct image *img,\n \tint i;\n \tchar *fixed_buf, *buf, *orig, *target;\n \tstruct strbuf fixed;\n-\tsize_t fixed_len;\n+\tsize_t fixed_len, postlen;\n \tint preimage_limit;\n \n \tif (preimage->nr + try_lno <= img->nr) {\n@@ -2335,6 +2335,7 @@ static int match_fragment(struct image *img,\n \tstrbuf_init(&fixed, preimage->len + 1);\n \torig = preimage->buf;\n \ttarget = img->buf + try;\n+\tpostlen = 0;\n \tfor (i = 0; i < preimage_limit; i++) {\n \t\tsize_t oldlen = preimage->line[i].len;\n \t\tsize_t tgtlen = img->line[try_lno + i].len;\n@@ -2362,6 +2363,7 @@ static int match_fragment(struct image *img,\n \t\tmatch = (tgtfix.len == fixed.len - fixstart &&\n \t\t\t !memcmp(tgtfix.buf, fixed.buf + fixstart,\n \t\t\t\t\t     fixed.len - fixstart));\n+\t\tpostlen += tgtfix.len;\n \n \t\tstrbuf_release(&tgtfix);\n \t\tif (!match)\n@@ -2399,8 +2401,10 @@ static int match_fragment(struct image *img,\n \t * hunk match.  Update the context lines in the postimage.\n \t */\n \tfixed_buf = strbuf_detach(&fixed, &fixed_len);\n+\tif (postlen < postimage->len)\n+\t\tpostlen = 0;\n \tupdate_pre_post_images(preimage, postimage,\n-\t\t\t       fixed_buf, fixed_len, 0);\n+\t\t\t       fixed_buf, fixed_len, postlen);\n \treturn 1;\n \n  unmatch_exit:\ndiff --git a/t/t4124-apply-ws-rule.sh b/t/t4124-apply-ws-rule.sh\nindex 6f6ee88..0bbcf06 100755\n--- a/t/t4124-apply-ws-rule.sh\n+++ b/t/t4124-apply-ws-rule.sh\n@@ -486,4 +486,30 @@ test_expect_success 'same, but with CR-LF line endings && cr-at-eol unset' '\n \ttest_cmp one expect\n '\n \n+test_expect_success 'whitespace=fix to expand' '\n+\tqz_to_tab_space >preimage <<-\\EOF &&\n+\tQQa\n+\tQQb\n+\tQQc\n+\tZZZZZZZZZZZZZZZZd\n+\tQQe\n+\tQQf\n+\tQQg\n+\tEOF\n+\tqz_to_tab_space >patch <<-\\EOF &&\n+\tdiff --git a/preimage b/preimage\n+\t--- a/preimage\n+\t+++ b/preimage\n+\t@@ -1,7 +1,6 @@\n+\t QQa\n+\t QQb\n+\t QQc\n+\t-QQd\n+\t QQe\n+\t QQf\n+\t QQg\n+\tEOF\n+\tgit -c core.whitespace=tab-in-indent apply --whitespace=fix patch\n+'\n+\n test_done\ndiff --git a/t/t4150-am.sh b/t/t4150-am.sh\nindex cdafd7e..12f6b02 100755\n--- a/t/t4150-am.sh\n+++ b/t/t4150-am.sh\n@@ -17,7 +17,7 @@ test_expect_success 'setup: messages' '\n \tvero eos et accusam et justo duo dolores et ea rebum.\n \n \tEOF\n-\tq_to_tab <<-\\EOF >>msg &&\n+\tqz_to_tab_space <<-\\EOF >>msg &&\n \tQDuis autem vel eum iriure dolor in hendrerit in vulputate velit\n \tQesse molestie consequat, vel illum dolore eu feugiat nulla facilisis\n \tQat vero eros et accumsan et iusto odio dignissim qui blandit\ndiff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh\nindex fa62d01..349f3b8 100644\n--- a/t/test-lib-functions.sh\n+++ b/t/test-lib-functions.sh\n@@ -87,8 +87,8 @@ q_to_cr () {\n \ttr Q '\\015'\n }\n \n-q_to_tab () {\n-\ttr Q '\\011'\n+qz_to_tab_space () {\n+\ttr QZ '\\011\\040'\n }\n \n append_cr () {\n"},{"id":"211986","messageId":"20130322212421.GA5079@sigill.intra.peff.net","threadId":"33107","inReplyTo":"7vip4j71dw.fsf@alter.siamese.dyndns.org","subject":"Re: Memory corruption when rebasing with git version 1.8.1.5 on arch","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2013-03-22T21:24:21Z","receivedAt":"2013-03-22T21:24:21Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Mar 22, 2013 at 11:08:59AM -0700, Junio C Hamano wrote:\n\n> This may be sufficient.  In the olden days, we relied on that all\n> whitespace fixing rules made the result shorter and took advantage\n> of it in update-pre-post-images to rewrite the images in place.  The\n> oddball tab-in-indent (aka Python), however, can grow the result by\n> expanding tabs (deemed \"incorrect\") in the input into runs of spaces\n> (deemed \"kosher\").\n> \n> Fortunately, we already support its more generalized form \"match\n> while ignoring whitespace differences\" that can lengthen the result;\n> as long as we correctly count the number of bytes needed to hold\n> rewritten postimage, the existing logic in update_pre_post_images\n> should be able to do the rest for us.\n\nYeah, your patch looks right to me. I do wonder if the optimization\nhere:\n\n> @@ -2399,8 +2401,10 @@ static int match_fragment(struct image *img,\n>  \t * hunk match.  Update the context lines in the postimage.\n>  \t */\n>  \tfixed_buf = strbuf_detach(&fixed, &fixed_len);\n> +\tif (postlen < postimage->len)\n> +\t\tpostlen = 0;\n>  \tupdate_pre_post_images(preimage, postimage,\n> -\t\t\t       fixed_buf, fixed_len, 0);\n> +\t\t\t       fixed_buf, fixed_len, postlen);\n\nshould simply go into update_pre_post_images (i.e., let it decide on\nwhether to do it inline or with a new allocation, rather than making\npostlen==0 special). That would let the ignore-whitespace code path use\nthe optimization, too (when it's possible).\n\nBy the way, I notice that when update_pre_post_images does allocate, the\nold value of postimage->buf is lost. It looks like that is not leaked,\nbecause it was pointing to a strbuf (newlines in apply_one_fragment)\nthat we are going to release anyway afterwards. But that means nobody is\nfreeing postimage->buf, which means that our newly malloc'd version is\ngetting leaked.\n\n-Peff\n"}]}