NetBSD-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: misc/49342: [test] lib/libc/gen/t_time.c is non-deterministic; compares set time vs current time (and can vary by a second under rare circumstances)



The following reply was made to PR misc/49342; it has been noted by GNATS.

From: Dennis Ferguson <dennis.c.ferguson%gmail.com@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: misc-bug-people%netbsd.org@localhost,
 gnats-admin%netbsd.org@localhost,
 netbsd-bugs%netbsd.org@localhost,
 yaneurabeya%gmail.com@localhost
Subject: Re: misc/49342: [test] lib/libc/gen/t_time.c is non-deterministic; compares set time vs current time (and can vary by a second under rare circumstances)
Date: Thu, 30 Oct 2014 15:59:17 -0700

 On 30 Oct, 2014, at 15:50 , Justin Cormack =
 <justin%specialbusservice.com@localhost> wrote:
 > On Thu, Oct 30, 2014 at 10:05 PM,  <yaneurabeya%gmail.com@localhost> wrote:
 >> The lib/libc/gen/t_time:time_timeofday testcase works in most cases, =
 but
 >> if the clock rolls over between when time and gettimeofday are =
 called, the value returned from time and the tv_sec value can vary =
 between, as noted in one of our Kyua runs on FreeBSD:
 >>=20
 >> Test case: lib/libc/gen/t_time:time_timeofday
 >=20
 >> The testcase should have "fuzzing" built in so it allows for a =
 maximum of 1 second difference between the two compared values.
 >=20
 > It could be worse than 1s, worst case, as this is not a monotonic
 > clock, and in either direction, in theory. Not a very good test, but I
 > suppose if we change to 10s wither way its fairly safe.
 
 I was going to say that the monotonic time() test in the same file
 was assuming that the time would never be wrong and in need of fixing,
 which doesn't match real life.
 
 For the other test it might be better to call time() after the call
 to gettimeofday(), as well as before, and only insist that =
 gettimeofday()
 match when the calls to time() have returned the same value.  This is
 also not quite perfect, but leaves some possibility of finding a problem
 by running the test with a fairly low probability of a false positive.
 
 Dennis Ferguson
 


Home | Main Index | Thread Index | Old Index