Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Improve error reporting for clock test #1248

Merged
merged 2 commits into from
Dec 16, 2022
Merged

Improve error reporting for clock test #1248

merged 2 commits into from
Dec 16, 2022

Conversation

kennykerr
Copy link
Collaborator

This test fails intermittently but it's hard to tell what's wrong since the error report doesn't include the failing values. This just ensures that we can see the values when it fails and perhaps gain some more insight in the failure.

@kennykerr kennykerr merged commit 69f9d8c into master Dec 16, 2022
@kennykerr kennykerr deleted the clock_test branch December 16, 2022 01:31
@alvinhochun
Copy link
Contributor

https://github.com/microsoft/cppwinrt/actions/runs/3719133191/jobs/6307790757#step:8:85

 4: -------------------------------------------------------------------------------
4: clock, time_t
4: -------------------------------------------------------------------------------
4: D:\a\cppwinrt\cppwinrt\test\old_tests\UnitTests\clock.cpp:67
4: ...............................................................................
4: 
4: D:\a\cppwinrt\cppwinrt\test\old_tests\UnitTests\clock.cpp:80: FAILED:
4:   REQUIRE( diff < 1000 )
4: with expansion:
4:   1001 (0x3e9) < 1000 (0x3e8)

Still have no idea why this fails randomly...

@alvinhochun
Copy link
Contributor

Ah, I have a suspicion: time(nullptr) has one-second resolution. Even when it is called at the 999th millisecond, the value it returns should be rounded down. If it was called first, it is possible that, when calling clock::now() the wall clock has ticked to the next second. This way, the difference between the two timestamp can slightly exceed 1000 milliseconds when unlucky.

The diff is calculated by abs(clock::now() - clock::from_time_t(time(nullptr))) in the same statement. I think because the order of evaluation is unspecified, the scenario described above may happen.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants