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
