monotonic_time unit test fail, 0.3.3.1-alpha debian armel

<weasel> util/monotonic_time:
<weasel>   FAIL ../src/test/test_util.c:5843: assert(msecc1 OP_LE nsecc1 / 1000000 + 1): 41399 vs 41395
<weasel>   [monotonic_time FAILED]
<weasel> https://buildd.debian.org/status/fetch.php?pkg=tor&arch=armel&ver=0.3.3.1-alpha-1&stamp=1517099318&raw=0

Looks like the armel build failed: https://buildd.debian.org/status/package.php?p=tor&suite=experimental

The comment in the unit tests right above that is

  /* We need to be a little careful here since we don't know the system load.

which makes me suspicious. :)

changed milestone to %Tor: 0.2.9.x-final

added 029-backport 031-unreached-backport 032-unreached-backport component::core tor/tor milestone::Tor: 0.2.9.x-final owner::dgoulet priority::medium resolution::fixed severity::normal status::closed tor-test type::defect version::tor 0.2.9.1-alpha labels

Wow ok so there is literally a 4msec gap between the nsecc1 and msecc1 function call on armel.

  nsecc1 = monotime_coarse_absolute_nsec();
  [usecc1 = monotime_coarse_absolute_usec();]
  msecc1 = monotime_coarse_absolute_msec();

So this test is doomed to fail on slow system because we get nsecc1 before msecc1 so shouldn't be msecc1 >= nsecc1 instead?

  tt_u64_op(msecc1, OP_LE, nsecc1 / 1000000 + 1);
  -> msecc1 <= nsecc1

Actually the whole set of checks between the 1 variables seems a bit weird, it assumes the clock gettime calls to be in the same msec range.

Also, clock_gettime() is a vdso in ARM exported since Linux 4.1 so if the build machine has an older kernel, the time gaps can be bigger.

Trac:
Status: new to needs_information
Keywords: N/A deleted, tor-test added

Quick discussion with nickm on IRC, bumping to 10msec is most likely what we want because we need to check for the synchronization between time read. Not ideal fix but for now that should do it.

If we ever encounter a system that will have a 10msec+ gap between the function call, we'll adapt at that point.

Branch: bug25113_033_01

Trac:
Owner: N/A to dgoulet
Status: needs_information to accepted

Kind of trivial fix so merge_ready.

Trac:
Status: accepted to merge_ready

Oh and the 029 branch for backport: bug25113_029_01

Trac:
Keywords: N/A deleted, 029-backport, 031-backport, 032-backport added

Merged to master; marking as backportable.

Trac:
Milestone: Tor: 0.3.3.x-final to Tor: 0.3.2.x-final

0.3.1 is end of life, there are no more backports. Tagging with 031-unreached-backport instead.

Trac:
Keywords: 031-backport deleted, 031-unreached-backport added

0.3.2 is end of life, so 032-backport is now 032-unreached-backport.

Trac:
Keywords: 032-backport deleted, 032-unreached-backport added

Trac:
Version: Tor: 0.3.3.1-alpha to Tor: 0.2.9.1-alpha

Trac:
Version: Tor: 0.2.9.1-alpha to N/A

These tickets can't be backported to 0.3.2, because it is end of life. But they can still be backported to 0.2.9.

Trac:
Milestone: Tor: 0.3.2.x-final to Tor: 0.2.9.x-final

This is a simple test-only change that makes the unit tests more reliable. It is a backport candidate.

But since the branch is old, I am opening a pull request to check CI still passes: https://github.com/torproject/tor/pull/748

Trac:
Version: N/A to Tor: 0.2.9.1-alpha

I merged #25116 (moved), #25113 (moved), and #24903 (moved) into 0.2.9.

CI passed on:

• the original branches,
• each branch merged into the current maint-0.2.9, and
• all 3 branches merged together into maint-0.2.9, then merged into release-0.2.9.

Trac:
Status: merge_ready to closed
Resolution: N/A to fixed

closed

mentioned in issue #25116 (moved)

moved to tpo/core/tor#25113 (closed)