[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: test-fdutimensat racy?
From: |
Pádraig Brady |
Subject: |
Re: test-fdutimensat racy? |
Date: |
Wed, 01 May 2013 02:03:51 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 |
On 04/30/2013 11:14 PM, Jim Meyering wrote:
> Bernhard Voelker wrote:
>> I'm having problems with the above test on different systems
>> for a while now. It aborts at different places.
>> Therefore, I've run it 1000 times like the following
>>
>> for f in $( seq 1000 ) ; do \
>> ./test-fdutimensat ; \
>> done 2>&1 | grep -v Aborted
>>
>> On a system I usually don't see problems with it (openSUSE-12.1, ext4),
>> I see 2-8 failures like this:
>>
>> test-futimens.h:57: assertion failed
>> test-lutimens.h:64: assertion failed
>> test-lutimens.h:162: assertion failed
>> test-utimens.h:130: assertion failed
>> test-utimens.h:103: assertion failed
>> test-utimens.h:130: assertion failed
>> test-utimens.h:119: assertion failed
>>
>> On openSUSE-12.2 with ext4, a VM in VirtualBox, I'm even getting
>> ~380 failures.
>>
>> Furthermore, I saw the same aborts on openSUSE Build Service when
>> running 'make check' for the coreutils package, and on SLES-10.3 (ext3).
>>
>> Any ideas?
>
> Yes, I've seen those repeatedly, over the years, especially in VMs,
> and more likely when run in parallel with other tests. Here's
> one thread about it:
>
> https://lists.gnu.org/archive/html/bug-gnulib/2011-11/msg00226.html
While it may be a kernel bug triggering the ctime issue,
it would be best to report that and try to avoid by
retrying with another nap() up to some maximum.
A more adaptive approach might be better though,
where we'd increase the nap() for each test.
We used a similar approach in coreutils tests
where a function would require a sufficient delay to _pass_
This was facilitated by the retry_delay_() wrapper function,
that would call the function under test with
a truncated exponential backoff.
thanks,
Pádraig.