Re: require_ulimit_v_(): tests skipped with enable-single-binary

[Pádraig Brady]

On 20/09/15 12:58, Bernhard Voelker wrote:
> On 09/20/2015 04:19 AM, Pádraig Brady wrote:
>> On 18/09/15 12:47, Pádraig Brady wrote:
>>> Another gotcha with ulimit is that setting it too low
>>> can disable any locale specific functionality,
>>> because setlocale() will fail below 120M in testing here,
>>> in which case we proceed in the "C" locale.
>>>
>>> For example, testing the recent fix for the sort -M mem leak,
>>> I was surprised that I couldn't trigger with:
>>>
>>>   yes | (ulimit -v15000 && strace -e brk sort -c -M >/dev/null)
>>>
>>> until I realized I needed to _increase_ the limit
>>>
>>>   yes | (ulimit -v150000 && strace -e brk sort -c -M >/dev/null)
>>>
> 
> wow, that is excessive.
> 
>>> p.s. using valgrind for mem leak checking is less general
>>> because it would depend on "lint" being defined to avoid all
>>> "definitely lost" warnings.
>>
>> BTW the 100MB virtual mem size increase from setlocale()
>> is caused by mmaping the pre-processed locale archive
>> at /usr/lib/locale/locale-archive.  That's CoW'd and so
>> doesn't use any extra RAM per process, but still
>> impacts ulimit -v.
> 
> I can not reproduce this effect here.
> Given the complexity of side effects of 'ulimit -v'-based tests
> in this case, I'm almost inclinded to go back to a valgrind'ed
> test which only runs when sort was compiled with -Dlint.

That's the approach taken in the updated:
https://github.com/pixelb/coreutils/commit/b429f5d8

> Would an adaptive 'ulimit -v'-based approach work, i.e. first
> getting the basic memory needed by e.g. "echo hello | sort -c -M",
> and then use that limit (plus a little more) for a run with much
> more input?

Also an adaptive `ulimit -v` is awkward anywhere the tools are adaptive
to memory limits themselves. There is the setlocale() gotcha for
all tools, but sort(1) for example will adjust its heap allocations
down to that available (see initbuf()).

cheers,
Pádraig.