On Sun, Jan 08, 2017 at 05:07:04PM +0200, Steve Langasek wrote: > So far I can't reproduce this problem here in unstable.
The failure rate is very small, less than 5%, so make sure you try a lot of times. While doing so you might find other failing tests that I did not report yet, like readdir, which I see failing here: https://tests.reproducible-builds.org/debian/logs/unstable/armhf/gawk_4.1.3+dfsg-0.1.build2.log.gz > The gawk test case does have a guard against race conditions here, by > requiring a call to the gawk strftime() implementation to return the same > value both before and after a call to the 'date' command. Yes, you mean this: before = strftime(fmt) datecmd | getline sd after = strftime(fmt) I was naively going to suggest "race condition" until I read that. > [...] > > When the failure happens, are there any messages in syslog about ntp > changing the clock? I do my builds in some sort of autobuilder farm, so I don't have an easy way to check see syslog when the failure happens. > My best theory at the moment is that the gawk strftime() is called; then > time passes, the clock reads that we're in the next second; then 'date' is > called; then ntp detects the clock has skewed, so sets it backwards some > fraction of time, to a point earlier than the most recent second boundary; > then gawk's strftime() is called again. This would explain the result that > both before and after strftime() calls return the same value, but the call > to date in between returns a different value that's in the future. > > If this is the reason, then I don't think it should be treated as a bug in > gawk. There's no good way to do an end-to-end test of a time-dependent > function like gawk's strftime() on a system with an unreliable clock. > gawk's strftime() does take an optional timestamp argument, but if you make > the test use a fixed timestamp, you're then testing a different code path. I don't like your theory because it would mean my clocks are very bad indeed :-) All my autobuilders are virtual machines. All of them have ntp installed. Nearly all hosts have ntp installed as well. The ntp mechanism was designed to not move the clock forward and backwards but instead smoothly (unless the difference is so big that it's better to make a "jump"). > Interestingly, the gawk README does say that strftime is one of a few tests > that may report failures from make check. So what's the theory in the README to explain the failures? Was the comment written after or before the guard against race conditions? Thanks.
