Control: tags -1 moreinfo unreproducible Hi Santiago,
On Sat, Jan 07, 2017 at 05:46:03PM +0000, Santiago Vila wrote: > ============== _strftime ============= > *** strftime.ok Fri Jan 6 01:30:24 2017 > --- _strftime Fri Jan 6 01:30:24 2017 > *************** > *** 1 **** > ! Fri Jan 6 01:30:25 GMT 2017 > --- 1 ---- > ! Fri Jan 6 01:30:24 GMT 2017 So far I can't reproduce this problem here in unstable. 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. So this shows a genuine difference between the results, which I don't know how to explain as a bug in the gawk implementation. Nor can I explain why it would occur only intermittently. > I've put several build logs here: > https://people.debian.org/~sanvila/build-logs/gawk/ > If this is really a bug in one of the build-depends, please use reassign and > affects, > so that this is still visible in the page for this package. > The bug should be reproducible with sbuild on a single CPU virtual machine, > provided you try enough times (as the failure happens randomly). When the failure happens, are there any messages in syslog about ntp changing the clock? 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. Interestingly, the gawk README does say that strftime is one of a few tests that may report failures from make check. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: PGP signature
