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

[Bernhard Voelker]

On 12/16/2015 07:48 PM, Pádraig Brady wrote:
> On 16/12/15 09:51, Pádraig Brady wrote:

>> 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.

That sounds sensible, thanks.

Have a nice day,
Berny