{"thread":{"id":"55766","subject":"RE: [ANNOUNCE] Git v2.32.0-rc1 - Defect in t0301.3, t1092.6, t5300","startedAt":"2021-05-24T22:37:42Z","lastAt":"2021-05-25T15:28:44Z","messageCount":5,"participants":["Randall S. Becker","Taylor Blau"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"425463","messageId":"036b01d750ed$642b75c0$2c826140$@nexbridge.com","threadId":"55766","inReplyTo":null,"subject":"RE: [ANNOUNCE] Git v2.32.0-rc1 - Defect in t0301.3, t1092.6, t5300","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-05-24T22:37:29Z","receivedAt":"2021-05-24T22:37:42Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":">Subject: Re: [ANNOUNCE] Git v2.32.0-rc1\n\nOn running the test suite on NonStop, t1092 fails in subtest 6 - but not when run with --verbose and -x, so I can't supply a log. This may be timing related. I wanted to report this in case anyone had any insight on whether there are any possible transient vulnerabilities. t0301.3 often has transient failures - which has been experienced for a while. Most importantly, t5300 continues to fail completely on the x86 platform, but not ia64, which I previously reported.\n\n-Randall\n\n\n"},{"id":"425464","messageId":"YKwsSgtfhaGq5z8k@nand.local","threadId":"55766","inReplyTo":"036b01d750ed$642b75c0$2c826140$@nexbridge.com","subject":"Re: [ANNOUNCE] Git v2.32.0-rc1 - Defect in t0301.3, t1092.6, t5300","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2021-05-24T22:44:26Z","receivedAt":"2021-05-24T22:44:32Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Mon, May 24, 2021 at 06:37:29PM -0400, Randall S. Becker wrote:\n> On running the test suite on NonStop, t1092 fails in subtest 6 - but\n> not when run with --verbose and -x, so I can't supply a log. This may\n> be timing related. I wanted to report this in case anyone had any\n> insight on whether there are any possible transient vulnerabilities.\n\nThe failure in t1092 sounds should be addressed by\n\n https://lore.kernel.org/git/pull.960.git.1621886108515.gitgitgadget@gmail.com/\n\n> t0301.3 often has transient failures - which has been experienced for\n> a while. Most importantly, t5300 continues to fail completely on the\n> x86 platform, but not ia64, which I previously reported.\n\nNot sure about these, though.\n\nThanks,\nTaylor\n"},{"id":"425523","messageId":"037d01d75168$5a5aaea0$0f100be0$@nexbridge.com","threadId":"55766","inReplyTo":"YKwsSgtfhaGq5z8k@nand.local","subject":"RE: [ANNOUNCE] Git v2.32.0-rc1 - Defect in t0301.3, t1092.6, t5300","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-05-25T13:17:40Z","receivedAt":"2021-05-25T13:18:49Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On May 24, 2021 6:44 PM, Taylor Blau wrote:\n>To: Randall S. Becker \n>Cc: 'Junio C Hamano' ; 'Jean-Noël AVILA' ; git@vger.kernel.org\n>Subject: Re: [ANNOUNCE] Git v2.32.0-rc1 - Defect in t0301.3, t1092.6, t5300\n>\n>On Mon, May 24, 2021 at 06:37:29PM -0400, Randall S. Becker wrote:\n>> On running the test suite on NonStop, t1092 fails in subtest 6 - but\n>> not when run with --verbose and -x, so I can't supply a log. This may\n>> be timing related. I wanted to report this in case anyone had any\n>> insight on whether there are any possible transient vulnerabilities.\n>\n>The failure in t1092 sounds should be addressed by\n>\n> https://lore.kernel.org/git/pull.960.git.1621886108515.gitgitgadget@gmail.com/\n>\n>> t0301.3 often has transient failures - which has been experienced for\n>> a while. Most importantly, t5300 continues to fail completely on the\n>> x86 platform, but not ia64, which I previously reported.\n>\n>Not sure about these, though.\n\nThanks will wait for the roll on that one. We had one loggable transient failure in t1096.15:\n\nexpecting success of 1092.15 'merge with outside renames':\n init_repos &&\n\n for type in out-to-out out-to-in in-to-out\n do\n test_all_match git reset --hard &&\n test_all_match git checkout -f -b merge-$type update-deep &&\n test_all_match git merge -m \"$type\" rename-$type &&\n test_all_match git rev-parse HEAD^{tree} || return 1\n done\n\n+ init_repos\nUpdating files: 100% (14/14), done.\nHEAD is now at 5d0e8a6 initial commit\nUpdating files: 100% (14/14), done.\nHEAD is now at 5d0e8a6 initial commit\nUpdating files: 100% (14/14), done.\nHEAD is now at 5d0e8a6 initial commit\nUpdating files: 100% (10/10), done.\nUpdating files: 100% (7/7), done.\nUpdating files: 100% (10/10), done.\nUpdating files: 100% (7/7), done.\n+ test_all_match git reset --hard\n+ test_all_match git checkout -f -b merge-out-to-out update-deep\n+ test_all_match git merge -m out-to-out rename-out-to-out\n--- full-checkout-err 2021-05-24 22:49:44 +0000\n+++ sparse-checkout-err 2021-05-24 22:49:50 +0000\n@@ -1 +0,0 @@\nUpdating files: 100% (5/5), done.\n+ return 1\nerror: last command exited with $?=1\nnot ok 15 - merge with outside renames\n#\n# init_repos &&\n#\n# for type in out-to-out out-to-in in-to-out\n# do\n# test_all_match git reset --hard &&\n# test_all_match git checkout -f -b merge-$type update-deep &&\n# test_all_match git merge -m \"$type\" rename-$type &&\n# test_all_match git rev-parse HEAD^{tree} || return 1\n# done\n#\n\n\n"},{"id":"425525","messageId":"YK0TKVZidW/G8XBr@nand.local","threadId":"55766","inReplyTo":"037d01d75168$5a5aaea0$0f100be0$@nexbridge.com","subject":"Re: [ANNOUNCE] Git v2.32.0-rc1 - Defect in t0301.3, t1092.6, t5300","fromName":"Taylor Blau","fromEmail":"me@ttaylorr.com","sentAt":"2021-05-25T15:09:29Z","receivedAt":"2021-05-25T15:09:38Z","isPatch":false,"sender":{"key":"me@ttaylorr.com","avatar":"https://avatars.githubusercontent.com/u/301000140?v=4"},"body":"On Tue, May 25, 2021 at 09:17:40AM -0400, Randall S. Becker wrote:\n> On May 24, 2021 6:44 PM, Taylor Blau wrote:\n> >To: Randall S. Becker \n> >Cc: 'Junio C Hamano' ; 'Jean-Noël AVILA' ; git@vger.kernel.org\n> >Subject: Re: [ANNOUNCE] Git v2.32.0-rc1 - Defect in t0301.3, t1092.6, t5300\n> >\n> >On Mon, May 24, 2021 at 06:37:29PM -0400, Randall S. Becker wrote:\n> >> On running the test suite on NonStop, t1092 fails in subtest 6 - but\n> >> not when run with --verbose and -x, so I can't supply a log. This may\n> >> be timing related. I wanted to report this in case anyone had any\n> >> insight on whether there are any possible transient vulnerabilities.\n> >\n> >The failure in t1092 sounds should be addressed by\n> >\n> > https://lore.kernel.org/git/pull.960.git.1621886108515.gitgitgadget@gmail.com/\n> >\n> >> t0301.3 often has transient failures - which has been experienced for\n> >> a while. Most importantly, t5300 continues to fail completely on the\n> >> x86 platform, but not ia64, which I previously reported.\n> >\n> >Not sure about these, though.\n>\n> Thanks will wait for the roll on that one. We had one loggable transient failure in t1096.15:\n>\n> expecting success of 1092.15 'merge with outside renames':\n> init_repos &&\n>\n> for type in out-to-out out-to-in in-to-out\n> do\n> test_all_match git reset --hard &&\n> test_all_match git checkout -f -b merge-$type update-deep &&\n> test_all_match git merge -m \"$type\" rename-$type &&\n> test_all_match git rev-parse HEAD^{tree} || return 1\n> done\n>\n> + init_repos\n> Updating files: 100% (14/14), done.\n> HEAD is now at 5d0e8a6 initial commit\n> Updating files: 100% (14/14), done.\n> HEAD is now at 5d0e8a6 initial commit\n> Updating files: 100% (14/14), done.\n> HEAD is now at 5d0e8a6 initial commit\n> Updating files: 100% (10/10), done.\n> Updating files: 100% (7/7), done.\n> Updating files: 100% (10/10), done.\n> Updating files: 100% (7/7), done.\n> + test_all_match git reset --hard\n> + test_all_match git checkout -f -b merge-out-to-out update-deep\n> + test_all_match git merge -m out-to-out rename-out-to-out\n> --- full-checkout-err 2021-05-24 22:49:44 +0000\n> +++ sparse-checkout-err 2021-05-24 22:49:50 +0000\n> @@ -1 +0,0 @@\n> Updating files: 100% (5/5), done.\n> + return 1\n> error: last command exited with $?=1\n\nI'm having trouble reading this: is 'return 1' part of the output\nwritten to sparse-checkout-err?\n\nIn either case, the \"updating files\" progress meter is coming from\nunpack-trees.c:get_progress(). Looking a little further:\n\n - get_progress() is called by check_updates(), which is called by\n unpack_trees() and update_sparsity()\n\n - update_sparsity() is called by the sparse-checkout builtin, which\n sets 'o.verbose_update = isatty(2)', so that caller is good.\n\n - 'git merge' is the last command invoked by t1092.15, and it calls\n unpack_trees() from 'builtin/merge.c:read_tree_trivial()', and sets\n 'opts.verbose_update = 1'.\n\nStolee's patch to set GIT_PROGRESS_DELAY=-1 will obviously take care of\nthis, but we should probably apply something like this on top (and maybe\nlook further at other callers of unpack_trees() to make sure they set\nopts.verbose_update correctly; I stopped after I found the problem\nhere).\n\n--- >8 ---\n\ndiff --git a/builtin/merge.c b/builtin/merge.c\nindex eddb8ae70d..5f926d3edc 100644\n--- a/builtin/merge.c\n+++ b/builtin/merge.c\n@@ -677,7 +677,7 @@ static int read_tree_trivial(struct object_id *common, struct object_id *head,\n \topts.src_index = &the_index;\n \topts.dst_index = &the_index;\n \topts.update = 1;\n-\topts.verbose_update = 1;\n+\topts.verbose_update = isatty(2);\n \topts.trivial_merges_only = 1;\n \topts.merge = 1;\n \ttrees[nr_trees] = parse_tree_indirect(common);\n"},{"id":"425528","messageId":"039f01d7517a$a0e01920$e2a04b60$@nexbridge.com","threadId":"55766","inReplyTo":"YK0TKVZidW/G8XBr@nand.local","subject":"RE: [ANNOUNCE] Git v2.32.0-rc1 - Defect in t0301.3, t1092.6, t5300","fromName":"Randall S. Becker","fromEmail":"rsbecker@nexbridge.com","sentAt":"2021-05-25T15:28:29Z","receivedAt":"2021-05-25T15:28:44Z","isPatch":false,"sender":{"key":"randall.becker@nexbridge.ca","avatar":"https://avatars.githubusercontent.com/u/28956764?v=4"},"body":"On May 25, 2021 11:09 AM, Taylor Blau wrote:\n>On Tue, May 25, 2021 at 09:17:40AM -0400, Randall S. Becker wrote:\n>> On May 24, 2021 6:44 PM, Taylor Blau wrote:\n>> >To: Randall S. Becker \n>> >Cc: 'Junio C Hamano' ; 'Jean-Noël AVILA'\n>> >; git@vger.kernel.org\n>> >Subject: Re: [ANNOUNCE] Git v2.32.0-rc1 - Defect in t0301.3, t1092.6,\n>> >t5300\n>> >\n>> >On Mon, May 24, 2021 at 06:37:29PM -0400, Randall S. Becker wrote:\n>> >> On running the test suite on NonStop, t1092 fails in subtest 6 -\n>> >> but not when run with --verbose and -x, so I can't supply a log.\n>> >> This may be timing related. I wanted to report this in case anyone\n>> >> had any insight on whether there are any possible transient vulnerabilities.\n>> >\n>> >The failure in t1092 sounds should be addressed by\n>> >\n>> >\n>> > https://lore.kernel.org/git/pull.960.git.1621886108515.gitgitgadget@\n>> > gmail.com/\n>> >\n>> >> t0301.3 often has transient failures - which has been experienced\n>> >> for a while. Most importantly, t5300 continues to fail completely\n>> >> on the\n>> >> x86 platform, but not ia64, which I previously reported.\n>> >\n>> >Not sure about these, though.\n>>\n>> Thanks will wait for the roll on that one. We had one loggable transient failure in t1096.15:\n>>\n>> expecting success of 1092.15 'merge with outside renames':\n>> init_repos &&\n>>\n>> for type in out-to-out out-to-in in-to-out\n>> do\n>> test_all_match git reset --hard &&\n>> test_all_match git checkout -f -b merge-$type update-deep &&\n>> test_all_match git merge -m \"$type\" rename-$type &&\n>> test_all_match git rev-parse HEAD^{tree} || return 1\n>> done\n>>\n>> + init_repos\n>> Updating files: 100% (14/14), done.\n>> HEAD is now at 5d0e8a6 initial commit\n>> Updating files: 100% (14/14), done.\n>> HEAD is now at 5d0e8a6 initial commit\n>> Updating files: 100% (14/14), done.\n>> HEAD is now at 5d0e8a6 initial commit\n>> Updating files: 100% (10/10), done.\n>> Updating files: 100% (7/7), done.\n>> Updating files: 100% (10/10), done.\n>> Updating files: 100% (7/7), done.\n>> + test_all_match git reset --hard\n>> + test_all_match git checkout -f -b merge-out-to-out update-deep\n>> + test_all_match git merge -m out-to-out rename-out-to-out\n>> --- full-checkout-err 2021-05-24 22:49:44 +0000\n>> +++ sparse-checkout-err 2021-05-24 22:49:50 +0000\n>> @@ -1 +0,0 @@\n>> Updating files: 100% (5/5), done.\n>> + return 1\n>> error: last command exited with $?=1\n>I'm having trouble reading this: is 'return 1' part of the output written to sparse-checkout-err?\n\nThe resulted from using -x. So something returned a resolved value of 1 from a shell function, possibly test_all_match\n\n>In either case, the \"updating files\" progress meter is coming from unpack-trees.c:get_progress(). Looking a little further:\n>\n> - get_progress() is called by check_updates(), which is called by\n> unpack_trees() and update_sparsity()\n>\n> - update_sparsity() is called by the sparse-checkout builtin, which\n> sets 'o.verbose_update = isatty(2)', so that caller is good.\n>\n> - 'git merge' is the last command invoked by t1092.15, and it calls\n> unpack_trees() from 'builtin/merge.c:read_tree_trivial()', and sets\n> 'opts.verbose_update = 1'.\n>\n>Stolee's patch to set GIT_PROGRESS_DELAY=-1 will obviously take care of this, but we should probably apply something like this on top\n>(and maybe look further at other callers of unpack_trees() to make sure they set opts.verbose_update correctly; I stopped after I found the\n>problem here).\n>diff --git a/builtin/merge.c b/builtin/merge.c index eddb8ae70d..5f926d3edc 100644\n>--- a/builtin/merge.c\n>+++ b/builtin/merge.c\n>@@ -677,7 +677,7 @@ static int read_tree_trivial(struct object_id *common, struct object_id *head,\n> \topts.src_index = &the_index;\n> \topts.dst_index = &the_index;\n> \topts.update = 1;\n>-\topts.verbose_update = 1;\n>+\topts.verbose_update = isatty(2);\n> \topts.trivial_merges_only = 1;\n> \topts.merge = 1;\n> \ttrees[nr_trees] = parse_tree_indirect(common);\n\nThis particular run was done from a shell directly, so I'm not sure isatty would change anything, but it would during our Jenkins build.\n\nLooking forward to the merge.\n\n"}]}