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>

diff --git a/changes/bug25113 b/changes/bug25113
new file mode 100644 (file)
index 0000000..4a020b7
--- /dev/null
+++ b/changes/bug25113
@@ -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.

diff --git a/src/test/test_util.c b/src/test/test_util.c
index 0b707caeebd681f4e023623e6101859c6851bf48..dd122b250dcc653e81e8eee39bb32909a005d80f 100644 (file)
--- a/src/test/test_util.c
+++ b/src/test/test_util.c
@@ -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:
   ;