Opened 13 months ago
Last modified 3 months ago
#25113 merge_ready defect
monotonic_time unit test fail, 0.3.3.1-alpha debian armel
Reported by: | arma | Owned by: | dgoulet |
---|---|---|---|
Priority: | Medium | Milestone: | Tor: 0.2.9.x-final |
Component: | Core Tor/Tor | Version: | |
Severity: | Normal | Keywords: | tor-test, 029-backport, 031-unreached-backport, 032-unreached-backport |
Cc: | Actual Points: | ||
Parent ID: | Points: | ||
Reviewer: | Sponsor: |
Description
<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. :)
Child Tickets
Change History (10)
comment:1 Changed 12 months ago by
Keywords: | tor-test added |
---|---|
Status: | new → needs_information |
comment:2 Changed 12 months ago by
Owner: | set to dgoulet |
---|---|
Status: | needs_information → accepted |
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
comment:3 Changed 12 months ago by
Status: | accepted → merge_ready |
---|
Kind of trivial fix so merge_ready
.
comment:4 Changed 12 months ago by
Keywords: | 029-backport 031-backport 032-backport added |
---|
Oh and the 029 branch for backport: bug25113_029_01
comment:5 Changed 12 months ago by
Milestone: | Tor: 0.3.3.x-final → Tor: 0.3.2.x-final |
---|
Merged to master; marking as backportable.
comment:6 Changed 8 months ago by
Keywords: | 031-unreached-backport added; 031-backport removed |
---|
0.3.1 is end of life, there are no more backports.
Tagging with 031-unreached-backport instead.
comment:7 Changed 3 months ago by
Keywords: | 032-unreached-backport added; 032-backport removed |
---|
0.3.2 is end of life, so 032-backport is now 032-unreached-backport.
comment:8 Changed 3 months ago by
Version: | Tor: 0.3.3.1-alpha → Tor: 0.2.9.1-alpha |
---|
comment:9 Changed 3 months ago by
Version: | Tor: 0.2.9.1-alpha |
---|
comment:10 Changed 3 months ago by
Milestone: | Tor: 0.3.2.x-final → Tor: 0.2.9.x-final |
---|
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.
Wow ok so there is literally a 4msec gap between the
nsecc1
andmsecc1
function call on armel.So this test is doomed to fail on slow system because we get
nsecc1
beforemsecc1
so shouldn't bemsecc1 >= nsecc1
instead?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.