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.
