{"thread":{"id":"33677","subject":"git rev-list | git cherry-pick --stdin is leaky","startedAt":"2013-04-30T00:11:04Z","lastAt":"2013-05-09T17:24:35Z","messageCount":7,"participants":["Stephen Boyd","Junio C Hamano","René Scharfe"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"215942","messageId":"517F0C18.8060703@codeaurora.org","threadId":"33677","inReplyTo":null,"subject":"git rev-list | git cherry-pick --stdin is leaky","fromName":"Stephen Boyd","fromEmail":"sboyd@codeaurora.org","sentAt":"2013-04-30T00:11:04Z","receivedAt":"2013-04-30T00:11:04Z","isPatch":false,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"(resending since the attachment seems to make vger sad)\n\nHi,\n\nI'm running git rev-list | git cherry-pick --stdin on a range of about\n300 commits. Eventually the chery-pick dies with:\n\n    error: cannot fork() for commit: Cannot allocate memory\n\nRunning valgrind shows me that the tree traversal code is leaking\ngigabytes of memory (particularly unpack_callback). Since cherry-pick is\na very long running process all these allocations are never freed and\neventually I run out of memory. The worst offender and summary is:\n\n==7986== 938,956,692 (929,961,582 direct, 8,995,110 indirect) bytes in\n7,765,439 blocks are definitely lost in loss record 257 of 257\n==7986==    at 0x4C267CC: calloc (vg_replace_malloc.c:467)\n==7986==    by 0x4FAF57: xcalloc (wrapper.c:119)\n==7986==    by 0x4F5281: unpack_callback (unpack-trees.c:539)\n==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n==7986==\n==7986== LEAK SUMMARY:\n==7986==    definitely lost: 2,514,117,692 bytes in 21,210,861 blocks\n==7986==    indirectly lost: 885,481,947 bytes in 10,165,801 blocks\n==7986==      possibly lost: 650,712,395 bytes in 6,014,309 blocks\n==7986==    still reachable: 7,734,870 bytes in 47,794 blocks\n==7986==         suppressed: 0 bytes in 0 blocks\n\nThis is against recent git.git\n(89740333e8d398f1da701e9023675321bbb9a85b). A workaround is to limit the\namount of commits per cherry-pick invocation, but can we somehow fix the\nleaks?\n\n-- \nQualcomm Innovation Center, Inc. is a member of Code Aurora Forum,\nhosted by The Linux Foundation\n"},{"id":"216038","messageId":"7vsj27dg5d.fsf@alter.siamese.dyndns.org","threadId":"33677","inReplyTo":"517F0C18.8060703@codeaurora.org","subject":"Re: git rev-list | git cherry-pick --stdin is leaky","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2013-04-30T18:31:26Z","receivedAt":"2013-04-30T18:31:26Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Stephen Boyd <sboyd@codeaurora.org> writes:\n\n> (resending since the attachment seems to make vger sad)\n>\n> Hi,\n>\n> I'm running git rev-list | git cherry-pick --stdin on a range of about\n> 300 commits. Eventually the chery-pick dies with:\n>\n>     error: cannot fork() for commit: Cannot allocate memory\n\nUnfortunately, I am not very surprised.\n\nThe merge-recursive machinery was designed in the \"run once and let\nexit() clean up after ourselves\" manner, which lets it not even\nhaving to worry about keeping track of what needs to be cleaned up.\nReusing it inside cherry-pick and revert without updating it was OK,\nbut extending cherry-pick and revert to take more than one change\nwithout addressing its resource management was a large mistake.\n\nI vaguely recall suggesting to fork and perform a three-way merge in\na separate process when operating on more than one commit when this\nfeature was first discussed.  We may have to do something like that.\n"},{"id":"216090","messageId":"51804A02.6080301@lsrfire.ath.cx","threadId":"33677","inReplyTo":"517F0C18.8060703@codeaurora.org","subject":"Re: git rev-list | git cherry-pick --stdin is leaky","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2013-04-30T22:47:30Z","receivedAt":"2013-04-30T22:47:30Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 30.04.2013 02:11, schrieb Stephen Boyd:\n> (resending since the attachment seems to make vger sad)\n> \n> Hi,\n> \n> I'm running git rev-list | git cherry-pick --stdin on a range of about\n> 300 commits. Eventually the chery-pick dies with:\n> \n>      error: cannot fork() for commit: Cannot allocate memory\n> \n> Running valgrind shows me that the tree traversal code is leaking\n> gigabytes of memory (particularly unpack_callback). Since cherry-pick is\n> a very long running process all these allocations are never freed and\n> eventually I run out of memory. The worst offender and summary is:\n> \n> ==7986== 938,956,692 (929,961,582 direct, 8,995,110 indirect) bytes in\n> 7,765,439 blocks are definitely lost in loss record 257 of 257\n> ==7986==    at 0x4C267CC: calloc (vg_replace_malloc.c:467)\n> ==7986==    by 0x4FAF57: xcalloc (wrapper.c:119)\n> ==7986==    by 0x4F5281: unpack_callback (unpack-trees.c:539)\n> ==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n> ==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n> ==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n> ==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n> ==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n> ==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n> ==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n> ==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n> ==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n> ==7986==\n> ==7986== LEAK SUMMARY:\n> ==7986==    definitely lost: 2,514,117,692 bytes in 21,210,861 blocks\n> ==7986==    indirectly lost: 885,481,947 bytes in 10,165,801 blocks\n> ==7986==      possibly lost: 650,712,395 bytes in 6,014,309 blocks\n> ==7986==    still reachable: 7,734,870 bytes in 47,794 blocks\n> ==7986==         suppressed: 0 bytes in 0 blocks\n\nI looked at that particular leak a year ago but couldn't convince myself\nto submit the patch below.  If the callback function we call through\ncall_unpack_fn does something strange like free()ing entries itself or\nadding them to some list without duplication then the added free() can\ncause trouble.\n\nLooking at it again today I don't understand that concern any more.  The\ncurrent callback functions don't do something like that, in any case.\nMaybe I'm missing something.\n\nAnyway, could you please check if the patch helps with your use case?\n\nThanks,\nRené\n\n\ndiff --git a/unpack-trees.c b/unpack-trees.c\nindex ede4299..67bc698 100644\n--- a/unpack-trees.c\n+++ b/unpack-trees.c\n@@ -590,8 +590,13 @@ static int unpack_nondirectories(int n, unsigned long mask,\n \t\tsrc[i + o->merge] = create_ce_entry(info, names + i, stage);\n \t}\n \n-\tif (o->merge)\n-\t\treturn call_unpack_fn(src, o);\n+\tif (o->merge) {\n+\t\tint ret = call_unpack_fn(src, o);\n+\t\tfor (i = 1; i < n + 1; i++)\n+\t\t\tif (src[i] && src[i] != o->df_conflict_entry)\n+\t\t\t\tfree(src[i]);\n+\t\treturn ret;\n+\t}\n \n \tfor (i = 0; i < n; i++)\n \t\tif (src[i] && src[i] != o->df_conflict_entry)\n"},{"id":"216164","messageId":"51815E77.8080601@codeaurora.org","threadId":"33677","inReplyTo":"51804A02.6080301@lsrfire.ath.cx","subject":"Re: git rev-list | git cherry-pick --stdin is leaky","fromName":"Stephen Boyd","fromEmail":"sboyd@codeaurora.org","sentAt":"2013-05-01T18:27:03Z","receivedAt":"2013-05-01T18:27:03Z","isPatch":false,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"On 04/30/13 15:47, René Scharfe wrote:\n> Am 30.04.2013 02:11, schrieb Stephen Boyd:\n>> (resending since the attachment seems to make vger sad)\n>>\n>> Hi,\n>>\n>> I'm running git rev-list | git cherry-pick --stdin on a range of about\n>> 300 commits. Eventually the chery-pick dies with:\n>>\n>>      error: cannot fork() for commit: Cannot allocate memory\n>>\n>> Running valgrind shows me that the tree traversal code is leaking\n>> gigabytes of memory (particularly unpack_callback). Since cherry-pick is\n>> a very long running process all these allocations are never freed and\n>> eventually I run out of memory. The worst offender and summary is:\n>>\n>> ==7986== 938,956,692 (929,961,582 direct, 8,995,110 indirect) bytes in\n>> 7,765,439 blocks are definitely lost in loss record 257 of 257\n>> ==7986==    at 0x4C267CC: calloc (vg_replace_malloc.c:467)\n>> ==7986==    by 0x4FAF57: xcalloc (wrapper.c:119)\n>> ==7986==    by 0x4F5281: unpack_callback (unpack-trees.c:539)\n>> ==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n>> ==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n>> ==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n>> ==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n>> ==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n>> ==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n>> ==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n>> ==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n>> ==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n>> ==7986==\n>> ==7986== LEAK SUMMARY:\n>> ==7986==    definitely lost: 2,514,117,692 bytes in 21,210,861 blocks\n>> ==7986==    indirectly lost: 885,481,947 bytes in 10,165,801 blocks\n>> ==7986==      possibly lost: 650,712,395 bytes in 6,014,309 blocks\n>> ==7986==    still reachable: 7,734,870 bytes in 47,794 blocks\n>> ==7986==         suppressed: 0 bytes in 0 blocks\n> I looked at that particular leak a year ago but couldn't convince myself\n> to submit the patch below.  If the callback function we call through\n> call_unpack_fn does something strange like free()ing entries itself or\n> adding them to some list without duplication then the added free() can\n> cause trouble.\n>\n> Looking at it again today I don't understand that concern any more.  The\n> current callback functions don't do something like that, in any case.\n> Maybe I'm missing something.\n>\n> Anyway, could you please check if the patch helps with your use case?\n\nOk I think I will make a copy of my .git first before I try out your\npatch. In case you're curious here are the next big leaks.\n\n==7986== 433,116,790 (432,950,308 direct, 166,482 indirect) bytes in 4,146,402 blocks are definitely lost in loss record 253 of 257\n==7986==    at 0x4C267CC: calloc (vg_replace_malloc.c:467)\n==7986==    by 0x4FAF57: xcalloc (wrapper.c:119)\n==7986==    by 0x4F5281: unpack_callback (unpack-trees.c:539)\n==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n==7986==    by 0x4F6FAE: unpack_trees (unpack-trees.c:1074)\n==7986==    by 0x4AD095: git_merge_trees (merge-recursive.c:241)\n==7986==    by 0x4AF3D5: merge_trees (merge-recursive.c:1811)\n==7986==    by 0x4D9A7A: do_pick_commit (sequencer.c:311)\n==7986==\n==7986== 482,083,201 (46,465,928 direct, 435,617,273 indirect) bytes in 93 blocks are definitely lost in loss record 255 of 257\n==7986==    at 0x4C267CC: calloc (vg_replace_malloc.c:467)\n==7986==    by 0x4FAF57: xcalloc (wrapper.c:119)\n==7986==    by 0x4C4AE4: read_index_from (read-cache.c:1452)\n==7986==    by 0x4D99BC: do_pick_commit (sequencer.c:297)\n==7986==    by 0x4DA750: pick_commits (sequencer.c:995)\n==7986==    by 0x4DAFD6: sequencer_pick_revisions (sequencer.c:1124)\n==7986==    by 0x463E7C: cmd_cherry_pick (revert.c:236)\n==7986==    by 0x404C86: handle_internal_command (git.c:284)\n==7986==    by 0x40541C: main (git.c:492)\n==7986==\n==7986== 557,706,880 (548,062,684 direct, 9,644,196 indirect) bytes in 4,931,819 blocks are definitely lost in loss record 256 of 257\n==7986==    at 0x4C267CC: calloc (vg_replace_malloc.c:467)\n==7986==    by 0x4FAF57: xcalloc (wrapper.c:119)\n==7986==    by 0x4F5281: unpack_callback (unpack-trees.c:539)\n==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n==7986==    by 0x4F6FAE: unpack_trees (unpack-trees.c:1074)\n==7986==    by 0x4AD095: git_merge_trees (merge-recursive.c:241)\n==7986==\n\nFull report can be found at https://gist.github.com/bebarino/5497181\n\n-- \nQualcomm Innovation Center, Inc. is a member of Code Aurora Forum,\nhosted by The Linux Foundation\n"},{"id":"216547","messageId":"51880FB7.8020701@codeaurora.org","threadId":"33677","inReplyTo":"51804A02.6080301@lsrfire.ath.cx","subject":"Re: git rev-list | git cherry-pick --stdin is leaky","fromName":"Stephen Boyd","fromEmail":"sboyd@codeaurora.org","sentAt":"2013-05-06T20:16:55Z","receivedAt":"2013-05-06T20:16:55Z","isPatch":false,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"On 04/30/13 15:47, René Scharfe wrote:\n> Am 30.04.2013 02:11, schrieb Stephen Boyd:\n>> (resending since the attachment seems to make vger sad)\n>>\n>> Hi,\n>>\n>> I'm running git rev-list | git cherry-pick --stdin on a range of about\n>> 300 commits. Eventually the chery-pick dies with:\n>>\n>>      error: cannot fork() for commit: Cannot allocate memory\n>>\n>> Running valgrind shows me that the tree traversal code is leaking\n>> gigabytes of memory (particularly unpack_callback). Since cherry-pick is\n>> a very long running process all these allocations are never freed and\n>> eventually I run out of memory. The worst offender and summary is:\n>>\n>> ==7986== 938,956,692 (929,961,582 direct, 8,995,110 indirect) bytes in\n>> 7,765,439 blocks are definitely lost in loss record 257 of 257\n>> ==7986==    at 0x4C267CC: calloc (vg_replace_malloc.c:467)\n>> ==7986==    by 0x4FAF57: xcalloc (wrapper.c:119)\n>> ==7986==    by 0x4F5281: unpack_callback (unpack-trees.c:539)\n>> ==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n>> ==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n>> ==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n>> ==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n>> ==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n>> ==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n>> ==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n>> ==7986==    by 0x4F586C: unpack_callback (unpack-trees.c:467)\n>> ==7986==    by 0x4F40E5: traverse_trees (tree-walk.c:407)\n>> ==7986==\n>> ==7986== LEAK SUMMARY:\n>> ==7986==    definitely lost: 2,514,117,692 bytes in 21,210,861 blocks\n>> ==7986==    indirectly lost: 885,481,947 bytes in 10,165,801 blocks\n>> ==7986==      possibly lost: 650,712,395 bytes in 6,014,309 blocks\n>> ==7986==    still reachable: 7,734,870 bytes in 47,794 blocks\n>> ==7986==         suppressed: 0 bytes in 0 blocks\n> I looked at that particular leak a year ago but couldn't convince myself\n> to submit the patch below.  If the callback function we call through\n> call_unpack_fn does something strange like free()ing entries itself or\n> adding them to some list without duplication then the added free() can\n> cause trouble.\n>\n> Looking at it again today I don't understand that concern any more.  The\n> current callback functions don't do something like that, in any case.\n> Maybe I'm missing something.\n>\n> Anyway, could you please check if the patch helps with your use case?\n\nOk. I tested it and it definitely helps.\n\n==10728== LEAK SUMMARY:\n==10728==    definitely lost: 316,355,458 bytes in 8,652 blocks\n==10728==    indirectly lost: 1,327,251,588 bytes in 16,180,628 blocks\n==10728==      possibly lost: 677,049,918 bytes in 7,381,801 blocks\n==10728==    still reachable: 9,238,039 bytes in 63,947 blocks\n==10728==         suppressed: 0 bytes in 0 blocks\n\nvs.\n\n==27614== LEAK SUMMARY:\n==27614==    definitely lost: 2,369,692,222 bytes in 20,005,707 blocks\n==27614==    indirectly lost: 829,151,786 bytes in 9,594,715 blocks\n==27614==      possibly lost: 658,069,373 bytes in 6,345,172 blocks\n==27614==    still reachable: 8,806,386 bytes in 50,199 blocks\n==27614==         suppressed: 0 bytes in 0 blocks\n\n-- \nQualcomm Innovation Center, Inc. is a member of Code Aurora Forum,\nhosted by The Linux Foundation\n"},{"id":"216771","messageId":"518BBC6D.9070006@lsrfire.ath.cx","threadId":"33677","inReplyTo":"51880FB7.8020701@codeaurora.org","subject":"Re: git rev-list | git cherry-pick --stdin is leaky","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2013-05-09T15:10:37Z","receivedAt":"2013-05-09T15:10:37Z","isPatch":false,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Am 06.05.2013 22:16, schrieb Stephen Boyd:\n> Ok. I tested it and it definitely helps.\n>\n> ==10728== LEAK SUMMARY:\n> ==10728==    definitely lost: 316,355,458 bytes in 8,652 blocks\n> ==10728==    indirectly lost: 1,327,251,588 bytes in 16,180,628 blocks\n> ==10728==      possibly lost: 677,049,918 bytes in 7,381,801 blocks\n> ==10728==    still reachable: 9,238,039 bytes in 63,947 blocks\n> ==10728==         suppressed: 0 bytes in 0 blocks\n>\n> vs.\n>\n> ==27614== LEAK SUMMARY:\n> ==27614==    definitely lost: 2,369,692,222 bytes in 20,005,707 blocks\n> ==27614==    indirectly lost: 829,151,786 bytes in 9,594,715 blocks\n> ==27614==      possibly lost: 658,069,373 bytes in 6,345,172 blocks\n> ==27614==    still reachable: 8,806,386 bytes in 50,199 blocks\n> ==27614==         suppressed: 0 bytes in 0 blocks\n\nThanks, Stephen.  I'm going to prepare a series around that patch which \nwill (hopefully) show that freeing these entries is safe by passing only \nconst pointers down to the callbacks.  It's too late for 1.8.3, of \ncourse, but it shouldn't take another year as most of that series is \ndone already. :)\n\nWe still have an impressive amount of leakage here.  I wonder why \n\"indirectly lost\" increased so much.  Do you perhaps still have the full \noutput of valgrind for the run with the patch applied?\n\nThanks,\nRené\n"},{"id":"216799","messageId":"518BDBD3.8070602@codeaurora.org","threadId":"33677","inReplyTo":"518BBC6D.9070006@lsrfire.ath.cx","subject":"Re: git rev-list | git cherry-pick --stdin is leaky","fromName":"Stephen Boyd","fromEmail":"sboyd@codeaurora.org","sentAt":"2013-05-09T17:24:35Z","receivedAt":"2013-05-09T17:24:35Z","isPatch":false,"sender":{"key":"bebarino@gmail.com","avatar":"https://avatars.githubusercontent.com/u/38832?v=4"},"body":"On 05/09/13 08:10, René Scharfe wrote:\n> Am 06.05.2013 22:16, schrieb Stephen Boyd:\n>> Ok. I tested it and it definitely helps.\n>>\n>> ==10728== LEAK SUMMARY:\n>> ==10728==    definitely lost: 316,355,458 bytes in 8,652 blocks\n>> ==10728==    indirectly lost: 1,327,251,588 bytes in 16,180,628 blocks\n>> ==10728==      possibly lost: 677,049,918 bytes in 7,381,801 blocks\n>> ==10728==    still reachable: 9,238,039 bytes in 63,947 blocks\n>> ==10728==         suppressed: 0 bytes in 0 blocks\n>>\n>> vs.\n>>\n>> ==27614== LEAK SUMMARY:\n>> ==27614==    definitely lost: 2,369,692,222 bytes in 20,005,707 blocks\n>> ==27614==    indirectly lost: 829,151,786 bytes in 9,594,715 blocks\n>> ==27614==      possibly lost: 658,069,373 bytes in 6,345,172 blocks\n>> ==27614==    still reachable: 8,806,386 bytes in 50,199 blocks\n>> ==27614==         suppressed: 0 bytes in 0 blocks\n>\n> Thanks, Stephen.  I'm going to prepare a series around that patch\n> which will (hopefully) show that freeing these entries is safe by\n> passing only const pointers down to the callbacks.  It's too late for\n> 1.8.3, of course, but it shouldn't take another year as most of that\n> series is done already. :)\n\nYes I started trying to throw const around everywhere but then I just\nsent out the email in hopes someone had already solved this problem.\n\n>\n> We still have an impressive amount of leakage here.  I wonder why\n> \"indirectly lost\" increased so much.  Do you perhaps still have the\n> full output of valgrind for the run with the patch applied?\n\nI think it increased because the first one ran to completion while the\nsecond one failed half way through so it's not an apples to apples\ncomparison. I can re-run with a certain range that is known not to fail\nif you're interested, but I think you got the idea that the patch helps.\n\n-- \nQualcomm Innovation Center, Inc. is a member of Code Aurora Forum,\nhosted by The Linux Foundation\n"}]}