bug-gnulib
[Top][All Lists]
Advanced

[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.




reply via email to

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