On 10/09/17 13:27, Michael J Gruber wrote:
> Ramsay Jones venit, vidit, dixit 09.09.2017 15:13:
[snip]
>> 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.
>>
> 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
> 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
