[Patch][BZ 17506] fix tst-strcoll-overflow returning before timeout

[Leonhard Holz]

Well, the former implementation just relied on running into timeout 
because of swapping and collating time, but it could not guarantee it. 
With enough hardware resources (maybe 10GB memory and a high end cpu) 
the test would have completeted within the five minutes boundary - and 
then counted as failed.

Now the needed hardware resources to complete in time have been lowered 
a lot but the overall behaviour has not changed: If the test machine is 
capable enough the test does complete, if not it runs into timeout 
(there is still an allocation of 1GB). Because of this I decided to fix 
the test implementation to support both outcomes. If this feels to 
luxurious I'd vote for setting the timeout much lower (30s?) so that the 
test suite completes faster.

Best,
Leonhard

Am 04.11.2014 18:48, schrieb Siddhesh Poyarekar:
> On Sat, Oct 25, 2014 at 01:48:39PM +0200, Leonhard Holz wrote:
>> Modifies the test examination in test-skeleton.c so that a test can be
>> successful if it is interrupted or it returns uninterrupted with the
>> expected status. For this both EXPECTED_SIGNAL and EXPECTED_STATUS have to
>> be set, as is done in tst-strcoll-overflow.c.
>
> This is unnecessary.  The test is intended to catch crashes on any
> kind of overflows that may have been caused in strcoll due to large
> string inputs (CVE-2012-4412 for example).  The timeout and alarm are
> there because the non-cached version would go on forever since it was
> really slow.
>
> With your performance improvements the test completes sucessfully
> without a crash but it doesn't actually go through all four passes.
> The ideal fix to the test case would be to have a really large string
> that is not binary identical like it currently is, but that'll be
> quite hard to do right now.  For now, it should be sufficient to just
> get rid of the EXPECTED_SIGNAL, reduce the TIMEOUT to a smaller value
> and adjust the big comment in the test to reflect the new reality.
>
> Siddhesh
>