BIND 10 #924: Additional debugging for IntervalTimer test failure
BIND 10 Development
do-not-reply at isc.org
Fri May 13 07:43:30 UTC 2011
#924: Additional debugging for IntervalTimer test failure
-------------------------------------+-------------------------------------
Reporter: shane | Owner: shane
Type: task | Status: new
Priority: major | Milestone:
Component: | Sprint-20110517
Unclassified | Resolution:
Keywords: | Sensitive: 0
Defect Severity: N/A | Sub-Project: DNS
Feature Depending on Ticket: | Estimated Difficulty: 1.0
Add Hours to Ticket: 0 | Total Hours: 0
Internal?: 0 |
-------------------------------------+-------------------------------------
Description changed by shane:
Old description:
> http://bind10.isc.org/~tester/builder//BIND10/20110512185001-NetBSD5-amd64/logs/unittests.out
>
> This appears to be a "real" timer failure:
>
> [ RUN ] IntervalTimerTest.overwriteIntervalTimer
> interval_timer_unittest.cc:295: Failure
> Value of: delta < TIMER_MARGIN_MSEC
> Actual: false
> Expected: true
> [ FAILED ] IntervalTimerTest.overwriteIntervalTimer (640 ms)
>
> One thing is that we should change the test from this:
>
> EXPECT_TRUE(delta < TIMER_MARGIN_MSEC);
>
> To this:
>
> EXPECT_LT(delta, TIMER_MARGIN_MSEC);
>
> I think that would give us more information, like printing out the
> actual delta. Probably we should do this everywhere. Does that make some
> sense?
>
> Also, we could check for some clock skew, by replacing this:
>
> boost::posix_time::time_duration delta =
> (boost::posix_time::microsec_clock::universal_time() - start)
> - boost::posix_time::millisec(400 + 100);
>
> With this:
>
> boost::posix_time::time_duration test_runtime =
> (boost::posix_time::microsec_clock::universal_time() - start);
> EXPECT_GT(test_runtime, 0);
>
> boost::posix_time::time_duration delta =
> test_runtime - boost::posix_time::millisec(400 + 100);
>
> It won't catch cases where the clock jumps forward, but at least we can
> learn if the box has unstable time. (Note this may have nothing to do
> with this particular case... is this a virtual machine?)
New description:
http://bind10.isc.org/~tester/builder//BIND10/20110512185001-NetBSD5-amd64/logs/unittests.out
This appears to be a "real" timer failure:
{{{
[ RUN ] IntervalTimerTest.overwriteIntervalTimer
interval_timer_unittest.cc:295: Failure
Value of: delta < TIMER_MARGIN_MSEC
Actual: false
Expected: true
[ FAILED ] IntervalTimerTest.overwriteIntervalTimer (640 ms)
}}}
One thing is that we should change the test from this:
EXPECT_TRUE(delta < TIMER_MARGIN_MSEC);
To this:
EXPECT_LT(delta, TIMER_MARGIN_MSEC);
I think that would give us more information, like printing out the
actual delta. Probably we should do this everywhere. Does that make some
sense?
Also, we could check for some clock skew, by replacing this:
{{{
boost::posix_time::time_duration delta =
(boost::posix_time::microsec_clock::universal_time() - start)
- boost::posix_time::millisec(400 + 100);
}}}
With this:
{{{
boost::posix_time::time_duration test_runtime =
(boost::posix_time::microsec_clock::universal_time() - start);
EXPECT_GT(test_runtime, 0);
boost::posix_time::time_duration delta =
test_runtime - boost::posix_time::millisec(400 + 100);
}}}
It won't catch cases where the clock jumps forward, but at least we can
learn if the box has unstable time. (Note this may have nothing to do
with this particular case... is this a virtual machine?)
--
--
Ticket URL: <http://bind10.isc.org/ticket/924#comment:1>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development
More information about the bind10-tickets
mailing list