Re: [PATCH] tests: avoid intermittent ulimit -v failures

[Pádraig Brady]

On 16/12/15 09:51, Pádraig Brady wrote:
> On 16/12/15 02:15, Pádraig Brady wrote:
>> I got the continuous integration going again with:
>>
>>   http://git.sv.gnu.org/gitweb/?p=hydra-recipes.git;a=commitdiff;h=f2f1c98b
>>
>> but then noticed a failure on i686 linux at:
>>
>>   FAIL: tests/misc/cut-huge-range.sh (exit: 1)
>>   ============================================
>>   cut: error while loading shared libraries:
>>   libc.so.6: failed to map segment from shared object
>>
>> I'm not sure about the attached, but it might address the issue.
>> If not we can increase the limit further.
> 
> Actually the issue might have been due to
> and extra fork/exec associated with the pipe,
> in which case this would be more appropriate:
> 
> diff --git a/tests/misc/cut-huge-range.sh b/tests/misc/cut-huge-range.sh
> index 633ca85..001bcde 100755
> --- a/tests/misc/cut-huge-range.sh
> +++ b/tests/misc/cut-huge-range.sh
> @@ -51,15 +51,15 @@ CUT_MAX=$(echo $SIZE_MAX | sed "$subtract_one")
> 
>  # From coreutils-8.10 through 8.20, this would make cut try to allocate
>  # a 256MiB bit vector.
> -(ulimit -v $vm && : | cut -b$CUT_MAX- > err 2>&1) || fail=1
> +(ulimit -v $vm && cut -b$CUT_MAX- /dev/null > err 2>&1) || fail=1
> 
>  # Up to and including coreutils-8.21, cut would allocate possibly needed
>  # memory upfront.  Subsequently extra memory is no longer needed.
> -(ulimit -v $vm && : | cut -b1-$CUT_MAX >> err 2>&1) || fail=1
> +(ulimit -v $vm && cut -b1-$CUT_MAX /dev/null >> err 2>&1) || fail=1
> 
>  # Explicitly disallow values above CUT_MAX
> -(ulimit -v $vm && : | returns_ 1 cut -b$SIZE_MAX 2>/dev/null) || fail=1
> -(ulimit -v $vm && : | returns_ 1 cut -b$SIZE_OFLOW 2>/dev/null) || fail=1
> +(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

Spending a few minutes testing rather than speculating,
suggests my hunch about alignment was correct.
I could trigger on my system when I tightened the VM contraint
in get_min_ulimit_v_() from 1000 to 1, and then tested with:

  make SHELL=/bin/dash TESTS=tests/misc/cut-huge-range.sh check

Subtle variations to that on my system would not trigger.
With the get_min_ulimit_v_() patch applied (and using the correct
divisor of 1024 rather than 4), I could not trigger any issues
on my system in all get_min_ulimit_v_() using tests.

I'll also merge in the above change for defensive reasons.

cheers,
Pádraig.