FAIL: string/tst-strcoll-overflow

[Stefan Liebler]

On 01/23/2017 03:35 PM, Florian Weimer wrote:
> On 01/16/2017 09:24 AM, Stefan Liebler wrote:
>> On 01/13/2017 11:14 PM, H.J. Lu wrote:
>>> On x86-64 with 32GB RAM under kernel 4.9.3, I got
>>>
>>> string/tst-strcoll-overflow
>>> 0
>>> Expected signal 'Alarm clock' from child, got none
>>>
>>> Has anyone else seen this?
>>>
>> As information:
>> This test fails on s390 and a machine from Florian Weimer, too.
>> See "Re: [PATCH] support: Introduce new subdirectory for test
>> infrastructure"
>> https://sourceware.org/ml/libc-alpha/2016-12/msg00391.html and
>> follow-Ups.
>
> I came up with the attached patch to fix this test.
Do you know if there are archs / machines which run into the timeout 
after commit "strcoll: improve performance by removing the cache 
(#15884)" 
(https://sourceware.org/git/gitweb.cgi?p=glibc.git;h=0742aef6e52a935f9ccd69594831b56d807feef3)?
Before this commit, this test run into the timeout on my machine.

See comment from Siddhesh:
"Re: [Patch][BZ 17506] fix tst-strcoll-overflow returning before 
timeout" (https://sourceware.org/ml/libc-alpha/2014-11/msg00107.html):
Set the timeout to a value that is large enough to allow the test to
complete without an alarm on commodity hardware.  If someone finds
that it is not large enough they can always patch it to increase it.

On s390, the test is passing with your patch as strcoll returns far 
before the timeout.
On my intel / power machines, too.

Bye.
Stefan

>
> We could use file-based alias mappings to greatly reduce the amount of
> memory required for this test, but this should probably wait until after
> the release.
>
> Thanks,
> Florian