{"thread":{"id":"30325","subject":"Reverting a swath of commits consumes all memory and dies.","startedAt":"2012-04-24T16:14:03Z","lastAt":"2012-04-24T20:02:56Z","messageCount":2,"participants":["Nick Bowler","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"189970","messageId":"20120424161403.GA24738@elliptictech.com","threadId":"30325","inReplyTo":null,"subject":"Reverting a swath of commits consumes all memory and dies.","fromName":"Nick Bowler","fromEmail":"nbowler@elliptictech.com","sentAt":"2012-04-24T16:14:03Z","receivedAt":"2012-04-24T16:14:03Z","isPatch":false,"sender":{"key":"nbowler@elliptictech.com","avatar":null},"body":"Hi folks,\n\nI just noticed that git-revert when given a large batch of commits will\nconsume more and more memory as commits are reverted.  Eventually, git's\nusage exceeds about half of the available memory and dies because fork\nfails with -ENOMEM.  This appears to be gratuitous, because after git\ndies you can simply run\n\n  git reset --hard\n  git revert --continue\n\nand the revert will pick up right where it left off.  Reverting commits\none at a time also works.  I can reproduce it (for example) with the\nfollowing example, using current master git:\n\n  % git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git\n  % cd linux\n  % git revert --no-merges --no-edit HEAD~50..\n\nwatch git's memory usage increase indefinitely with \"top\", until...\n\n  error: cannot fork() for commit: Cannot allocate memory\n  fatal: revert failed\n\n  % git reset --hard\n  % git revert --no-edit --continue\n\nrepeat as needed until eventually there's few enough commits left that\nthe revert completes without running out of memory (or git-revert fails\nfor some other reason).\n\nCheers,\n-- \nNick Bowler, Elliptic Technologies (http://www.elliptictech.com/)\n"},{"id":"189989","messageId":"xmqqk414gaof.fsf@junio.mtv.corp.google.com","threadId":"30325","inReplyTo":"20120424161403.GA24738@elliptictech.com","subject":"Re: Reverting a swath of commits consumes all memory and dies.","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-04-24T20:02:56Z","receivedAt":"2012-04-24T20:02:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Nick Bowler <nbowler@elliptictech.com> writes:\n\n> I just noticed that git-revert when given a large batch of commits will\n> consume more and more memory as commits are reverted.\n\n[Cc: people who have been involved in builtin/revert.c and sequencer.c]\n\nUnfortunate, but not surprised.\n\nUnlike other sequencing operations like 'rebase' and 'am', multi-commit\ncherry-pick/revert were implemented in such a way that it calls into the\ninfrastructure functions that was meant to be used in \"get invoked as a\nsingle command, do that one thing well, and let exit(2) take care of\ncleaning up the resources\" repeatedly from within a single process.\nProbably the series that implemented multi-commit cherry-pick/revert\nshould have first updated the infrastructure to reduce leaks, but\nprobably it looked shinier to add features than doing the necessary\nlegwork ;-)\n\nPerhaps you (or anybody for that matter) can help by running them under\nvalgrind, which would be a good first step to find and fix the leaks.\n\nThanks.\n"}]}