Re: Unexpected pass for t6120-describe.sh on cygwin

From: Ramsay Jones <ramsay@ramsayjones.plus.com>
Date: Sep 10, 2017, 16:58 UTC
Message-ID: <2ef4b3b3-fa2f-ef06-203e-521b8cd6ecaa@ramsayjones.plus.com>
In-Reply-To: <947699e6-c206-7818-3780-c4367e0996f0@grubix.eu>

On 10/09/17 13:27, Michael J Gruber wrote:

> Ramsay Jones venit, vidit, dixit 09.09.2017 15:13:

[snip]

Show 7 quoted lines

>> So, it looks like all ULIMIT_STACK_SIZE tests need to be disabled
>> on cygwin. I also wonder about the ULIMIT_FILE_DESCRIPTORS tests,
>> but haven't looked into it.
>>
>> Given that 'ulimit' is a bash built-in, this may also be a problem
>> on MinGW and Git-For-Windows, but I can't test on those platforms.
>>

Show 10 quoted lines

> Thanks for the note. We have this in t/test-lib.sh:
> 
> run_with_limited_cmdline () {
>         (ulimit -s 128 && "$@")
> }
> 
> test_lazy_prereq CMDLINE_LIMIT 'run_with_limited_cmdline true'
> 
> This apparantly expects "ulimit -s" to fail on platforms that don't
> support it,

Indeed, but cygwin lies (about the stack, anyway) ... :-D

  $ ulimit -a
  core file size          (blocks, -c) unlimited
  data seg size           (kbytes, -d) unlimited
  file size               (blocks, -f) unlimited
  open files                      (-n) 256
  pipe size            (512 bytes, -p) 8
  stack size              (kbytes, -s) 2032
  cpu time               (seconds, -t) unlimited
  max user processes              (-u) 256
  virtual memory          (kbytes, -v) unlimited
  $ 
  $ ulimit -a -H
  core file size          (blocks, -c) unlimited
  data seg size           (kbytes, -d) unlimited
  file size               (blocks, -f) unlimited
  open files                      (-n) 3200
  pipe size            (512 bytes, -p) 8
  stack size              (kbytes, -s) unlimited
  cpu time               (seconds, -t) unlimited
  max user processes              (-u) 256
  virtual memory          (kbytes, -v) unlimited
  $

Note that ulimit claims that the soft limit for the stack is (2MB - 16kb), but the hard limit is unlimited. Using the test program, it is clear that it always segfaults on the soft limit, no matter what value is requested. (while not 'failing' the request).

Note, also, that the soft/hard limit on open files is 256/3200. (but I still haven't investigated if ulimit honours that limit yet).

               so set the prereq accordingly. I moved the following to

Show 13 quoted lines

> t/test-lib.sh:
> 
> run_with_limited_stack () {
>         (ulimit -s 128 && "$@")
> }
> 
> test_lazy_prereq ULIMIT_STACK_SIZE 'run_with_limited_stack true'
> 
> Same things as above. Two things to note:
> - Those requisites could be the same, also they are used in different ways.
> - "ulimit -s" returning success without doing anything means that, all
> along, we ran the existing tests when we didn't mean to (on Win), and
> they succeeded for the wrong reason, which we did not notice.

Yes.

> So, I guess, short of testing the effect of "ulimit -s" with another
> expensive test, it's best to simply set these prerequisites based on
> "uname -s".

Yes, I was going to suggest adding !CYGWIN to the test(s) (or perhaps to the 'test_lazy_prereq' expression(s)).

ATB, Ramsay Jones