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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 




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





[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux