test: Bump to 10 msec gap in the monotonic test

On slow system, 1 msec between one read and the other was too tight. For
instance, it failed on armel with a 4msec gap:

  https://buildd.debian.org/status/package.php?p=tor&suite=experimental

Increase to 10 msec for now to address slow system. It is important that we
keep this OP_LE test in so we make sure the msec/usec/nsec read aren't
desynchronized by huge gaps. We'll adjust again if we ever encounter a system
that goes slower than 10 msec between calls.

Fixes #25113

Signed-off-by: David Goulet <dgoulet@torproject.org>
This commit is contained in:
David Goulet 2018-02-07 10:23:24 -05:00
parent a2aaf9509b
commit fe3dfe7e38
2 changed files with 9 additions and 4 deletions

5
changes/bug25113 Normal file
View File

@ -0,0 +1,5 @@
o Minor bugfixes (unit test, monotonic time):
- Bump a gap of 1msec to 10msec used in the monotonic time test that makes
sure the nsec/usec/msec time read are synchronized. This change was
needed to accommodate slow system like armel or when the clock_gettime()
is not a VDSO on the running kernel. Fixes bug 25113; bugfix on 0.2.9.1.

View File

@ -5541,10 +5541,10 @@ test_util_monotonic_time(void *arg)
tt_u64_op(usec1, OP_GE, nsec1 / 1000);
tt_u64_op(msecc1, OP_GE, nsecc1 / 1000000);
tt_u64_op(usecc1, OP_GE, nsecc1 / 1000);
tt_u64_op(msec1, OP_LE, nsec1 / 1000000 + 1);
tt_u64_op(usec1, OP_LE, nsec1 / 1000 + 1000);
tt_u64_op(msecc1, OP_LE, nsecc1 / 1000000 + 1);
tt_u64_op(usecc1, OP_LE, nsecc1 / 1000 + 1000);
tt_u64_op(msec1, OP_LE, nsec1 / 1000000 + 10);
tt_u64_op(usec1, OP_LE, nsec1 / 1000 + 10000);
tt_u64_op(msecc1, OP_LE, nsecc1 / 1000000 + 10);
tt_u64_op(usecc1, OP_LE, nsecc1 / 1000 + 10000);
done:
;