bug#26253: tests/misc/cut-huge-range.sh fails on arm-linux-gnueabihf

[Pádraig Brady]

On 26/03/17 06:41, Ludovic Courtès wrote:
> Hi Pádraig,
> 
> We found that ‘tests/misc/cut-huge-range.sh’ would fail on our ARMv7
> GNU/Linux machines:
> 
>   https://bugs.gnu.org/26253
> 
> (I noticed there’s a thinko in the patch I used for Guix: ‘getconf
> PAGESIZE’ returns bytes whereas ‘ulimit -v’ expects kibibytes).
> 
> The reason for this failure is that the limit passed to ‘ulimit -v’
> would be slightly too low, even after Coreutils commit
> 28803c8a3144d5d4363cdbd148bbe067af1a67c2 (2004 KiB before and 3004KiB
> after this commit.)
> 
> Part of the reason, I think, is that ‘vm’ is computed by simply running
> ‘cut -b1’:
> 
>   vm=$(get_min_ulimit_v_ cut -b1 /dev/null) \
>     || skip_ "this shell lacks ulimit support"
> 
> … but the last couple of tests also run sh within that limit:

Are you saying the returns_ call induces a subshell?
I suppose it might on some shells, though it doesn't seem to on bash 4.3 here.

> 
>   # Explicitly disallow values above CUT_MAX
>   (ulimit -v $vm && returns_ 1 cut -b$SIZE_MAX /dev/null 2>/dev/null) || 
> fail=1
>   (ulimit -v $vm && returns_ 1 cut -b$SIZE_OFLOW /dev/null 2>/dev/null) || 
> fail=1
> 
> It might be more accurate to do something like:
> 
>   vm=$(get_min_ulimit_v_ sh -c 'cut -b1 /dev/null')

That give 10004 rather than 5004 on my x86_64 system here.
Another option might be to use:
  vm=$(get_min_ulimit_v_ returns_ 0 cut -b1 /dev/null)

Does that give better results for you?

> However it still seems easy to slightly underestimate the limit and get
> those spurious failures.
> 
> Thoughts?

We've bumped these limits up by fixed amounts in some cases,
so if we don't get a more general solution I'll apply your
patch to coreutils upstream, replacing `getconf PAGESIZE` with 4096.

cheers,
Pádraig