{"thread":{"id":"46730","subject":"Unexpected pass for t6120-describe.sh on cygwin","startedAt":"2017-09-09T13:13:40Z","lastAt":"2017-09-13T13:11:21Z","messageCount":9,"participants":["Ramsay Jones","Michael J Gruber","Adam Dinwoodie","Jeff King","Johannes Schindelin"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"327818","messageId":"7c3db153-2a56-f27d-af71-e4b61f1252a1@ramsayjones.plus.com","threadId":"46730","inReplyTo":null,"subject":"Unexpected pass for t6120-describe.sh on cygwin","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2017-09-09T13:13:32Z","receivedAt":"2017-09-09T13:13:40Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"Hi Adam,\n\nI ran the test-suite on the 'pu' branch last night (simply because\nthat was what I had built at the time!), which resulted in a PASS,\nbut t6120 was showing a 'TODO passed' for #52.\n\nThis is a test introduced by Michael's 'mg/name-rev-tests-with-short-stack'\nbranch, which uses 'ulimit -s' to try and force a stack overflow.\nUnfortunately, 'ulimit -s' seems to have no effect on cygwin. I created\na test program (see below) to eat up the stack and tried running it\nwith various ulimit values (128, 12, 8), but it always seg-faulted\nat the same stack-frame. (after using approx 2MB stack space).\n\nSo, it looks like all ULIMIT_STACK_SIZE tests need to be disabled\non cygwin. I also wonder about the ULIMIT_FILE_DESCRIPTORS tests,\nbut haven't looked into it.\n\nGiven that 'ulimit' is a bash built-in, this may also be a problem\non MinGW and Git-For-Windows, but I can't test on those platforms.\n\nUnfortunately, I can't spend more time on git today, hence this\nheads up! ;-)\n\nATB,\nRamsay Jones\n\n-- >8 --\ndiff --git a/test.c b/test.c\nnew file mode 100644\nindex 0000000..bcbb805\n--- /dev/null\n+++ b/test.c\n@@ -0,0 +1,21 @@\n+#include <stdio.h>\n+#include <stdlib.h>\n+#include <inttypes.h>\n+\n+void test(uint64_t count)\n+{\n+\tint i, junk[1024];\n+\n+\tfor (i = 0; i < 1024; i++)\n+\t\tjunk[i] = count;\n+\ti = junk[count % 1024];\n+\tprintf(\"%\" PRIuMAX \"\\n\", (uintmax_t)count);\n+\tfflush(stdout);\n+\ttest(count + 1);\n+}\n+\n+int main(int argc, char *argv[])\n+{\n+\ttest(0);\n+\treturn 0;\n+}\n\n"},{"id":"327832","messageId":"947699e6-c206-7818-3780-c4367e0996f0@grubix.eu","threadId":"46730","inReplyTo":"7c3db153-2a56-f27d-af71-e4b61f1252a1@ramsayjones.plus.com","subject":"Re: Unexpected pass for t6120-describe.sh on cygwin","fromName":"Michael J Gruber","fromEmail":"git@grubix.eu","sentAt":"2017-09-10T12:27:47Z","receivedAt":"2017-09-10T12:28:02Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Ramsay Jones venit, vidit, dixit 09.09.2017 15:13:\n> Hi Adam,\n> \n> I ran the test-suite on the 'pu' branch last night (simply because\n> that was what I had built at the time!), which resulted in a PASS,\n> but t6120 was showing a 'TODO passed' for #52.\n> \n> This is a test introduced by Michael's 'mg/name-rev-tests-with-short-stack'\n> branch, which uses 'ulimit -s' to try and force a stack overflow.\n> Unfortunately, 'ulimit -s' seems to have no effect on cygwin. I created\n> a test program (see below) to eat up the stack and tried running it\n> with various ulimit values (128, 12, 8), but it always seg-faulted\n> at the same stack-frame. (after using approx 2MB stack space).\n> \n> So, it looks like all ULIMIT_STACK_SIZE tests need to be disabled\n> on cygwin. I also wonder about the ULIMIT_FILE_DESCRIPTORS tests,\n> but haven't looked into it.\n> \n> Given that 'ulimit' is a bash built-in, this may also be a problem\n> on MinGW and Git-For-Windows, but I can't test on those platforms.\n> \n> Unfortunately, I can't spend more time on git today, hence this\n> heads up! ;-)\n\nThanks for the note. We have this in t/test-lib.sh:\n\nrun_with_limited_cmdline () {\n        (ulimit -s 128 && \"$@\")\n}\n\ntest_lazy_prereq CMDLINE_LIMIT 'run_with_limited_cmdline true'\n\nThis apparantly expects \"ulimit -s\" to fail on platforms that don't\nsupport it, so set the prereq accordingly. I moved the following to\nt/test-lib.sh:\n\nrun_with_limited_stack () {\n        (ulimit -s 128 && \"$@\")\n}\n\ntest_lazy_prereq ULIMIT_STACK_SIZE 'run_with_limited_stack true'\n\nSame things as above. Two things to note:\n- Those requisites could be the same, also they are used in different ways.\n- \"ulimit -s\" returning success without doing anything means that, all\nalong, we ran the existing tests when we didn't mean to (on Win), and\nthey succeeded for the wrong reason, which we did not notice.\n\nSo, I guess, short of testing the effect of \"ulimit -s\" with another\nexpensive test, it's best to simply set these prerequisites based on\n\"uname -s\".\n\n\n> ATB,\n> Ramsay Jones\n> \n> -- >8 --\n> diff --git a/test.c b/test.c\n> new file mode 100644\n> index 0000000..bcbb805\n> --- /dev/null\n> +++ b/test.c\n> @@ -0,0 +1,21 @@\n> +#include <stdio.h>\n> +#include <stdlib.h>\n> +#include <inttypes.h>\n> +\n> +void test(uint64_t count)\n> +{\n> +\tint i, junk[1024];\n> +\n> +\tfor (i = 0; i < 1024; i++)\n> +\t\tjunk[i] = count;\n> +\ti = junk[count % 1024];\n> +\tprintf(\"%\" PRIuMAX \"\\n\", (uintmax_t)count);\n> +\tfflush(stdout);\n> +\ttest(count + 1);\n> +}\n> +\n> +int main(int argc, char *argv[])\n> +{\n> +\ttest(0);\n> +\treturn 0;\n> +}\n> \n\n"},{"id":"327837","messageId":"2ef4b3b3-fa2f-ef06-203e-521b8cd6ecaa@ramsayjones.plus.com","threadId":"46730","inReplyTo":"947699e6-c206-7818-3780-c4367e0996f0@grubix.eu","subject":"Re: Unexpected pass for t6120-describe.sh on cygwin","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2017-09-10T16:58:49Z","receivedAt":"2017-09-10T16:59:00Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 10/09/17 13:27, Michael J Gruber wrote:\n> Ramsay Jones venit, vidit, dixit 09.09.2017 15:13:\n[snip]\n>> So, it looks like all ULIMIT_STACK_SIZE tests need to be disabled\n>> on cygwin. I also wonder about the ULIMIT_FILE_DESCRIPTORS tests,\n>> but haven't looked into it.\n>>\n>> Given that 'ulimit' is a bash built-in, this may also be a problem\n>> on MinGW and Git-For-Windows, but I can't test on those platforms.\n>>\n\n> Thanks for the note. We have this in t/test-lib.sh:\n> \n> run_with_limited_cmdline () {\n>         (ulimit -s 128 && \"$@\")\n> }\n> \n> test_lazy_prereq CMDLINE_LIMIT 'run_with_limited_cmdline true'\n> \n> This apparantly expects \"ulimit -s\" to fail on platforms that don't\n> support it, \n\nIndeed, but cygwin lies (about the stack, anyway) ... :-D\n\n  $ ulimit -a\n  core file size          (blocks, -c) unlimited\n  data seg size           (kbytes, -d) unlimited\n  file size               (blocks, -f) unlimited\n  open files                      (-n) 256\n  pipe size            (512 bytes, -p) 8\n  stack size              (kbytes, -s) 2032\n  cpu time               (seconds, -t) unlimited\n  max user processes              (-u) 256\n  virtual memory          (kbytes, -v) unlimited\n  $ \n  $ ulimit -a -H\n  core file size          (blocks, -c) unlimited\n  data seg size           (kbytes, -d) unlimited\n  file size               (blocks, -f) unlimited\n  open files                      (-n) 3200\n  pipe size            (512 bytes, -p) 8\n  stack size              (kbytes, -s) unlimited\n  cpu time               (seconds, -t) unlimited\n  max user processes              (-u) 256\n  virtual memory          (kbytes, -v) unlimited\n  $ \n\nNote that ulimit claims that the soft limit for the stack\nis (2MB - 16kb), but the hard limit is unlimited. Using the\ntest program, it is clear that it always segfaults on the\nsoft limit, no matter what value is requested. (while not\n'failing' the request).\n\nNote, also, that the soft/hard limit on open files is 256/3200.\n(but I still haven't investigated if ulimit honours that limit\nyet).\n\n               so set the prereq accordingly. I moved the following to\n> t/test-lib.sh:\n> \n> run_with_limited_stack () {\n>         (ulimit -s 128 && \"$@\")\n> }\n> \n> test_lazy_prereq ULIMIT_STACK_SIZE 'run_with_limited_stack true'\n> \n> Same things as above. Two things to note:\n> - Those requisites could be the same, also they are used in different ways.\n> - \"ulimit -s\" returning success without doing anything means that, all\n> along, we ran the existing tests when we didn't mean to (on Win), and\n> they succeeded for the wrong reason, which we did not notice.\n\nYes.\n\n> So, I guess, short of testing the effect of \"ulimit -s\" with another\n> expensive test, it's best to simply set these prerequisites based on\n> \"uname -s\".\n\nYes, I was going to suggest adding !CYGWIN to the test(s) (or perhaps\nto the 'test_lazy_prereq' expression(s)).\n\nATB,\nRamsay Jones\n\n\n"},{"id":"327847","messageId":"20170911103142.GH10378@dinwoodie.org","threadId":"46730","inReplyTo":"7c3db153-2a56-f27d-af71-e4b61f1252a1@ramsayjones.plus.com","subject":"Re: Unexpected pass for t6120-describe.sh on cygwin","fromName":"Adam Dinwoodie","fromEmail":"adam@dinwoodie.org","sentAt":"2017-09-11T10:31:42Z","receivedAt":"2017-09-11T10:31:51Z","isPatch":false,"sender":{"key":"adam@dinwoodie.org","avatar":"https://avatars.githubusercontent.com/u/1397507?v=4"},"body":"On Sat, Sep 09, 2017 at 02:13:32PM +0100, Ramsay Jones wrote:\n> I ran the test-suite on the 'pu' branch last night (simply because\n> that was what I had built at the time!), which resulted in a PASS,\n> but t6120 was showing a 'TODO passed' for #52.\n\nConfirmed, I also see this unexpected pass.\n\n> This is a test introduced by Michael's 'mg/name-rev-tests-with-short-stack'\n> branch, which uses 'ulimit -s' to try and force a stack overflow.\n> Unfortunately, 'ulimit -s' seems to have no effect on cygwin. I created\n> a test program (see below) to eat up the stack and tried running it\n> with various ulimit values (128, 12, 8), but it always seg-faulted\n> at the same stack-frame. (after using approx 2MB stack space).\n\nYes, Cygwin does not implement the ulimit API from the Single Unix\nSpecification, per https://cygwin.com/cygwin-api/std-notimpl.html.  I\nsuspect the Bash builtin still exists because (a) nobody has bothered to\nremove it, (b) including it avoids breaking scripts that assume it\nexists but don't particularly rely on its output being sensical, or\n(c) both.\n\n> So, it looks like all ULIMIT_STACK_SIZE tests need to be disabled\n> on cygwin. I also wonder about the ULIMIT_FILE_DESCRIPTORS tests,\n> but haven't looked into it.\n> \n> Given that 'ulimit' is a bash built-in, this may also be a problem\n> on MinGW and Git-For-Windows, but I can't test on those platforms.\n\nI'll leave this to the relevant folks to test; I don't have a useful\ntest environment for those either.  That said, I'll note the comment in\nt6120 says the ULIMIT_STACK_SIZE prerequisite excludes running the test\non Windows, so I assume it's not a problem there.\n\nOn Sun, Sep 10, 2017 at 05:58:49PM +0100, Ramsay Jones wrote:\n> On 10/09/17 13:27, Michael J Gruber wrote:\n> > So, I guess, short of testing the effect of \"ulimit -s\" with another\n> > expensive test, it's best to simply set these prerequisites based on\n> > \"uname -s\".\n> \n> Yes, I was going to suggest adding !CYGWIN to the test(s) (or perhaps\n> to the 'test_lazy_prereq' expression(s)).\n\nGiven the issue is Cygwin not implementing ulimit at all, but Cygwin\nBash pretending everything's fine, I think handling this as a special\ncase for Cygwin seems like the correct approach.  Something like the\nbelow, based on the existing code in test-lib.sh for the PIPE prereq?\n\n-- >8 --\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex 83f5d3dd2..376cd91ae 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -1166,14 +1166,32 @@ test_lazy_prereq UNZIP '\n \ttest $? -ne 127\n '\n \n+# On Cygwin, ulimit has no effect because the underlying API hasn't been\n+# implemented.  Just fail if trying to do something with ulimit.\n run_with_limited_cmdline () {\n-\t(ulimit -s 128 && \"$@\")\n+\tcase $(uname -s) in\n+\tCYGWIN*)\n+\t\tfalse\n+\t\t;;\n+\t*)\n+\t\t(ulimit -s 128 && \"$@\")\n+\t\t;;\n+\tesac\n }\n \n test_lazy_prereq CMDLINE_LIMIT 'run_with_limited_cmdline true'\n \n+# On Cygwin, ulimit has no effect because the underlying API hasn't been\n+# implemented.  Just fail if trying to do something with ulimit.\n run_with_limited_stack () {\n-\t(ulimit -s 128 && \"$@\")\n+\tcase $(uname -s) in\n+\tCYGWIN*)\n+\t\tfalse\n+\t\t;;\n+\t*)\n+\t\t(ulimit -s 128 && \"$@\")\n+\t\t;;\n+\tesac\n }\n \n test_lazy_prereq ULIMIT_STACK_SIZE 'run_with_limited_stack true'\n"},{"id":"327854","messageId":"20170911174711.j7ela4feg43gw34b@sigill.intra.peff.net","threadId":"46730","inReplyTo":"947699e6-c206-7818-3780-c4367e0996f0@grubix.eu","subject":"Re: Unexpected pass for t6120-describe.sh on cygwin","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2017-09-11T17:47:11Z","receivedAt":"2017-09-11T17:47:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Sep 10, 2017 at 02:27:47PM +0200, Michael J Gruber wrote:\n\n> This apparantly expects \"ulimit -s\" to fail on platforms that don't\n> support it, so set the prereq accordingly. I moved the following to\n> t/test-lib.sh:\n> \n> run_with_limited_stack () {\n>         (ulimit -s 128 && \"$@\")\n> }\n> \n> test_lazy_prereq ULIMIT_STACK_SIZE 'run_with_limited_stack true'\n> \n> Same things as above. Two things to note:\n> - Those requisites could be the same, also they are used in different ways.\n> - \"ulimit -s\" returning success without doing anything means that, all\n> along, we ran the existing tests when we didn't mean to (on Win), and\n> they succeeded for the wrong reason, which we did not notice.\n\nRight, if ulimit doesn't actually limit, then the test isn't really\naccomplishing anything. But we likely have several tests in our suite\nthat do that. As long as they do something on _some_ platforms, they're\nstill useful. And as long as their failure mode is a false-pass, they\ndon't bother people on the other platforms.\n\nSo I think one option is to just leave it.\n\n> So, I guess, short of testing the effect of \"ulimit -s\" with another\n> expensive test, it's best to simply set these prerequisites based on\n> \"uname -s\".\n\nYou can make a cheap test that uses a lot of stack. E.g., this program\nruns in about 3ms on my machine, and you can reliably run \"ulimit -s 128\n&& ./a.out >/dev/null\" to detect it segfaulting:\n\n-- >8 --\n#include <stdio.h>\n\n/*\n * Our goal is to use a lot of stack space relatively cheaply. To do that,\n * allocate a big stack buffer and recurse. But we take a few precautions to\n * avoid a clever compiler optimizing away our stack:\n *\n *   - we need to use the buffer so that it can't be eliminated\n *\n *   - we recurse after touching the buffer but before printing it,\n *     which makes it hard to do tail-recursion.\n */\nstatic void foo(unsigned x)\n{\n\tsize_t i;\n\tunsigned char buf[1024];\n\n\tif (!x)\n\t\treturn;\n\n\tfor (i = 0; i < sizeof(buf); i++)\n\t\tbuf[x] = x & 0xff;\n\n\tfoo(x - 1);\n\n\tfwrite(buf, 1, sizeof(buf), stdout);\n}\n\nint main(void)\n{\n\tfoo(128);\n\treturn 0;\n}\n-- 8< --\n\nOne downside is that it means git's test suite would (on a successful\nrun) stimulate segfaults, which are sometimes tracked and logged by the\nkernel (or may even generate coredumps outside of the test suite area).\n\n-Peff\n"},{"id":"327869","messageId":"32074a54-9a1c-f866-8ffe-033f188805f4@ramsayjones.plus.com","threadId":"46730","inReplyTo":"20170911103142.GH10378@dinwoodie.org","subject":"Re: Unexpected pass for t6120-describe.sh on cygwin","fromName":"Ramsay Jones","fromEmail":"ramsay@ramsayjones.plus.com","sentAt":"2017-09-11T22:17:06Z","receivedAt":"2017-09-11T22:17:17Z","isPatch":false,"sender":{"key":"ramsay@ramsayjones.plus.com","avatar":"https://avatars.githubusercontent.com/u/33702710?v=4"},"body":"\n\nOn 11/09/17 11:31, Adam Dinwoodie wrote:\n> On Sat, Sep 09, 2017 at 02:13:32PM +0100, Ramsay Jones wrote:\n>> I ran the test-suite on the 'pu' branch last night (simply because\n>> that was what I had built at the time!), which resulted in a PASS,\n>> but t6120 was showing a 'TODO passed' for #52.\n> \n> Confirmed, I also see this unexpected pass.\n> \n>> This is a test introduced by Michael's 'mg/name-rev-tests-with-short-stack'\n>> branch, which uses 'ulimit -s' to try and force a stack overflow.\n>> Unfortunately, 'ulimit -s' seems to have no effect on cygwin. I created\n>> a test program (see below) to eat up the stack and tried running it\n>> with various ulimit values (128, 12, 8), but it always seg-faulted\n>> at the same stack-frame. (after using approx 2MB stack space).\n> \n> Yes, Cygwin does not implement the ulimit API from the Single Unix\n> Specification, per https://cygwin.com/cygwin-api/std-notimpl.html.  I\n\nIsn't that ulimit(3) not ulimit the bash built-in - which would\nmore than likely be implemented by {get,set}rlimit(). (I haven't\nlooked to find out, obviously!).\n\n> suspect the Bash builtin still exists because (a) nobody has bothered to\n> remove it, (b) including it avoids breaking scripts that assume it\n> exists but don't particularly rely on its output being sensical, or\n> (c) both.\n\n(d) it seems to provide useful information on some of the limits anyway.\n\n>> So, it looks like all ULIMIT_STACK_SIZE tests need to be disabled\n>> on cygwin. I also wonder about the ULIMIT_FILE_DESCRIPTORS tests,\n>> but haven't looked into it.\n>>\n>> Given that 'ulimit' is a bash built-in, this may also be a problem\n>> on MinGW and Git-For-Windows, but I can't test on those platforms.\n> \n> I'll leave this to the relevant folks to test; I don't have a useful\n> test environment for those either.  That said, I'll note the comment in\n> t6120 says the ULIMIT_STACK_SIZE prerequisite excludes running the test\n> on Windows, so I assume it's not a problem there.\n\nI suspect that was a guess. ;-)\n\n> On Sun, Sep 10, 2017 at 05:58:49PM +0100, Ramsay Jones wrote:\n>> On 10/09/17 13:27, Michael J Gruber wrote:\n>>> So, I guess, short of testing the effect of \"ulimit -s\" with another\n>>> expensive test, it's best to simply set these prerequisites based on\n>>> \"uname -s\".\n>>\n>> Yes, I was going to suggest adding !CYGWIN to the test(s) (or perhaps\n>> to the 'test_lazy_prereq' expression(s)).\n> \n> Given the issue is Cygwin not implementing ulimit at all, but Cygwin\n> Bash pretending everything's fine, I think handling this as a special\n> case for Cygwin seems like the correct approach.  Something like the\n> below, based on the existing code in test-lib.sh for the PIPE prereq?\n> \n> -- >8 --\n> diff --git a/t/test-lib.sh b/t/test-lib.sh\n> index 83f5d3dd2..376cd91ae 100644\n> --- a/t/test-lib.sh\n> +++ b/t/test-lib.sh\n> @@ -1166,14 +1166,32 @@ test_lazy_prereq UNZIP '\n>  \ttest $? -ne 127\n>  '\n>  \n> +# On Cygwin, ulimit has no effect because the underlying API hasn't been\n> +# implemented.  Just fail if trying to do something with ulimit.\n>  run_with_limited_cmdline () {\n> -\t(ulimit -s 128 && \"$@\")\n> +\tcase $(uname -s) in\n> +\tCYGWIN*)\n> +\t\tfalse\n> +\t\t;;\n> +\t*)\n> +\t\t(ulimit -s 128 && \"$@\")\n> +\t\t;;\n> +\tesac\n>  }\n>  \n>  test_lazy_prereq CMDLINE_LIMIT 'run_with_limited_cmdline true'\n>  \n> +# On Cygwin, ulimit has no effect because the underlying API hasn't been\n> +# implemented.  Just fail if trying to do something with ulimit.\n>  run_with_limited_stack () {\n> -\t(ulimit -s 128 && \"$@\")\n> +\tcase $(uname -s) in\n> +\tCYGWIN*)\n> +\t\tfalse\n> +\t\t;;\n> +\t*)\n> +\t\t(ulimit -s 128 && \"$@\")\n> +\t\t;;\n> +\tesac\n>  }\n>  \n>  test_lazy_prereq ULIMIT_STACK_SIZE 'run_with_limited_stack true'\n> \n\nWhat about the other uses of ulimit? (No, I still haven't tried\nulimit with open file descriptors - I will assume it doesn't work).\n\nI was thinking something more like this:\n\n  $ git diff\n  diff --git a/t/test-lib.sh b/t/test-lib.sh\n  index 83f5d3dd2..6c939708a 100644\n  --- a/t/test-lib.sh\n  +++ b/t/test-lib.sh\n  @@ -1009,6 +1009,11 @@ case $uname_s in\n          GIT_TEST_CMP=mingw_test_cmp\n          ;;\n   *CYGWIN*)\n  +       # the ulimit bash built-in is ineffective\n  +       # but always succeeds, so always fail instead\n  +       ulimit () {\n  +               false\n  +       }\n          test_set_prereq POSIXPERM\n          test_set_prereq EXECKEEPSPID\n          test_set_prereq CYGWIN\n  $ \n\nThis assumes that 'ulimit -n 32' fails to limit the number\nof open files, of course.\n\nATB,\nRamsay Jones\n\n"},{"id":"327889","messageId":"alpine.DEB.2.21.1.1709121538360.4132@virtualbox","threadId":"46730","inReplyTo":"7c3db153-2a56-f27d-af71-e4b61f1252a1@ramsayjones.plus.com","subject":"Re: Unexpected pass for t6120-describe.sh on cygwin","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-09-12T13:39:38Z","receivedAt":"2017-09-12T13:39:52Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Ramsay,\n\nOn Sat, 9 Sep 2017, Ramsay Jones wrote:\n\n> I ran the test-suite on the 'pu' branch last night (simply because that\n> was what I had built at the time!), which resulted in a PASS, but t6120\n> was showing a 'TODO passed' for #52.\n> \n> This is a test introduced by Michael's 'mg/name-rev-tests-with-short-stack'\n> branch, which uses 'ulimit -s' to try and force a stack overflow.\n> Unfortunately, 'ulimit -s' seems to have no effect on cygwin. I created\n> a test program (see below) to eat up the stack and tried running it with\n> various ulimit values (128, 12, 8), but it always seg-faulted at the\n> same stack-frame. (after using approx 2MB stack space).\n> \n> So, it looks like all ULIMIT_STACK_SIZE tests need to be disabled\n> on cygwin. I also wonder about the ULIMIT_FILE_DESCRIPTORS tests, but\n> haven't looked into it.\n> \n> Given that 'ulimit' is a bash built-in, this may also be a problem on\n> MinGW and Git-For-Windows, but I can't test on those platforms.\n\nIt is.\n\nThanks,\nDscho\n"},{"id":"327918","messageId":"52f990d5-cdac-b516-269c-acbb68897e6e@grubix.eu","threadId":"46730","inReplyTo":"alpine.DEB.2.21.1.1709121538360.4132@virtualbox","subject":"Re: Unexpected pass for t6120-describe.sh on cygwin","fromName":"Michael J Gruber","fromEmail":"git@grubix.eu","sentAt":"2017-09-13T09:08:13Z","receivedAt":"2017-09-13T09:08:27Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johannes Schindelin venit, vidit, dixit 12.09.2017 15:39:\n> Hi Ramsay,\n> \n> On Sat, 9 Sep 2017, Ramsay Jones wrote:\n> \n>> I ran the test-suite on the 'pu' branch last night (simply because that\n>> was what I had built at the time!), which resulted in a PASS, but t6120\n>> was showing a 'TODO passed' for #52.\n>>\n>> This is a test introduced by Michael's 'mg/name-rev-tests-with-short-stack'\n>> branch, which uses 'ulimit -s' to try and force a stack overflow.\n>> Unfortunately, 'ulimit -s' seems to have no effect on cygwin. I created\n>> a test program (see below) to eat up the stack and tried running it with\n>> various ulimit values (128, 12, 8), but it always seg-faulted at the\n>> same stack-frame. (after using approx 2MB stack space).\n>>\n>> So, it looks like all ULIMIT_STACK_SIZE tests need to be disabled\n>> on cygwin. I also wonder about the ULIMIT_FILE_DESCRIPTORS tests, but\n>> haven't looked into it.\n>>\n>> Given that 'ulimit' is a bash built-in, this may also be a problem on\n>> MinGW and Git-For-Windows, but I can't test on those platforms.\n> \n> It is.\n\nThanks.\n\nI just dug something up from an old cygwin list post. Could you please\ntry and report on the following (cygwin, MinGW):\n\nulimit -s\nulimit -s 4096 # anything lower than the value from above\nulimit -s\nbash -c \"ulimit -s\"\n\nMy suspicion from that post is that ulimit affects the sub shell only -\nif yes, running a test inside the sub shell to confirm whether the\nsetting is in effect would be great, of course. /usr/bin/echo $(seq\n100000) or such does the job on Linux (with stack limit 128), but I\ndon't know whether this is portably reliable.\n\nIf ulimit on these platforms has no effect but does not lie about the\nvalue either it's a simple prerequisite test (test ulimit present, if\nyes set and get and compare the stack size values).\n\nMichael\n"},{"id":"327934","messageId":"alpine.DEB.2.21.1.1709131448390.4132@virtualbox","threadId":"46730","inReplyTo":"52f990d5-cdac-b516-269c-acbb68897e6e@grubix.eu","subject":"Re: Unexpected pass for t6120-describe.sh on cygwin","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2017-09-13T13:11:07Z","receivedAt":"2017-09-13T13:11:21Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi Michael,\n\nOn Wed, 13 Sep 2017, Michael J Gruber wrote:\n\n> Could you please try and report on the following (cygwin, MinGW):\n> \n> ulimit -s\n> ulimit -s 4096 # anything lower than the value from above\n> ulimit -s\n> bash -c \"ulimit -s\"\n\nGit Bash (MINGW, well, not precisely [*1*]):\n\n\tme@work MINGW64 ~\n\t$ ulimit -s\n\t2032\n\n\tme@work MINGW64 ~\n\t$ ulimit -s 4096 # anything lower than the value from above\n\n\tme@work MINGW64 ~\n\t$ ulimit -s\n\t4096\n\n\tme@work MINGW64 ~\n\t$ bash -c \"ulimit -s\"\n\t2032\n\nJudging by your comment, 4096 should be replaced. So here goes again:\n\n\tme@work MINGW64 ~\n\t$ ulimit -s 1024\n\n\tme@work MINGW64 ~\n\t$ ulimit -s\n\t1024\n\n\tme@work MINGW64 ~\n\t$ bash -c \"ulimit -s\"\n\t2032\n\nAnd here is the same output of my 64-bit Cygwin installation (just updated\nto the current [*2*] one):\n\n\tme@work  ~\n\t$ ulimit -s\n\t2032\n\n\tme@work  ~\n\t$ ulimit -s 1024\n\n\tme@work  ~\n\t$ ulimit -s\n\t1024\n\n\tme@work  ~\n\t$ bash -c \"ulimit -s\"\n\t2032\n\nCiao,\nDscho\n\nFootnote *1*: I know it is confusing for Linux folks, there are two very\ndifferent classes of executables in Git for Windows: MSYS2 ones and MINGW\nones. The former implicitly link against the MSYS2 runtime, and therefore\ncan make use of its POSIX emulation layer, the latter do not, and\ntherefore they can use \"only\" what the Win32 API provides. For details,\nsee\nhttps://github.com/git-for-windows/git/wiki/The-difference-between-MINGW-and-MSYS2\n"}]}