coreutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Pádraig Brady
Subject: Re: require_ulimit_v_(): tests skipped with enable-single-binary
Date: Tue, 22 Sep 2015 02:41:31 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0

On 22/09/15 02:13, Bernhard Voelker wrote:
> On 09/21/2015 02:56 AM, Pádraig Brady wrote:
>> On 21/09/15 00:47, Bernhard Voelker wrote:
>>> >From 1335ab2713aab020564275c49fdb3e92bb9a207b Mon Sep 17 00:00:00 2001
>>> From: Bernhard Voelker <address@hidden>
>>> Date: Mon, 21 Sep 2015 01:40:33 +0200
>>> Subject: [PATCH] maint: use adaptive approach for `ulimit -v` based tests
>>>
>>> When configured with either 'symlinks' or 'shebangs' as value for
>>> the --enable-single-binary option, tests based on `ulimit -v` are
>>> skipped.  The reason is that the multicall 'coreutils' binary requires
>>> much more memory due to shared libraries being loaded, and the size of
>>> the 'date' binary (~290KiB) compared to the multicall binary (~5MiB),
>>> of course.  Finally, in the case of 'shebangs', the starting shell
>>> requires more memory, too
>>>
>>> Instead of using hard-coded values for the memory limit, use an
>>> adaptive approach: first determine the amount of memory for a similar,
>>> yet more trivial command, and then do the real test run using that
>>
>> s/command/invocation of the command/
>>
>> I can't find any significant issues with the patch at all.
> 
> Thanks, I'll push with that change tomorrow.
> 
>> In future for i18n significant `ulimit -v`, we might have gen_min_ulimit_v_()
>> do additional checking of setlocale() output with non "C" locales
>> (I notice locale(1) doesn't set the exit value appropriately upon failure 
>> :/),
>> and use that as additional space to add on top of the current adaptive 
>> method?
> 
> Using the above adaptive gen_min_ulimit_v_(), isn't the attached sufficient
> for tests/i18n/sort-month.sh (both patches on top of your I18N branch)?
> 
> BTW: I've found another strange issue with "sort -Mu" swallowing one output 
> line
> (therefore I had to use the extra uniq(1) in the attached patch for now):
> 
>   $ printf ".\nɑ\n" | 
> /var/tmp/build-root/openSUSE_Factory-x86_64/usr/bin/sort -M
>   .
>   ɑ
>   $ printf "ɑ\n.\n" | 
> /var/tmp/build-root/openSUSE_Factory-x86_64/usr/bin/sort -M
>   .
>   ɑ
>   $ printf ".\nɑ\n" | 
> /var/tmp/build-root/openSUSE_Factory-x86_64/usr/bin/sort -Mu
>   .
>   $ printf "ɑ\n.\n" | 
> /var/tmp/build-root/openSUSE_Factory-x86_64/usr/bin/sort -Mu
>   ɑ
> 
> Interestingly, the effect is not limited to I18N but also happens with git 
> master;
> 'sort -Mu' seems to discard all but one of the non-month input lines:
> 
>   $ printf "b\na\n" | LC_ALL=C ~/coreutils/src/sort -Mu
>   b
>   $ printf "a\nb\n" | LC_ALL=C ~/coreutils/src/sort -Mu
>   a
>   $ printf "Nov\nDec\na\nb\n" | LC_ALL=C ~/coreutils/src/sort -Mu
>   a
>   Nov
>   Dec
> 
> I don't think this is intended, is it?

When there is no match, the lines compare equal.
Same for -n etc:

  $ printf '%s\n' a b c | LC_ALL=C sort -nu --debug
  sort: using simple byte comparison
  a
  ^ no match for key

cheers,
Pádraig.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]