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

runtime: frequent TestGcLastTime failures on windows-arm64 #48072

Open
bcmills opened this issue Aug 30, 2021 · 6 comments
Open

runtime: frequent TestGcLastTime failures on windows-arm64 #48072

bcmills opened this issue Aug 30, 2021 · 6 comments

Comments

@bcmills
Copy link
Member Author

@bcmills bcmills commented Aug 30, 2021

These failures are new as of Go 1.17 because windows-arm64 support itself is new as of Go 1.17, so marking as release-blocker for the next release: we should not allow builder flakiness to increase from one release to the next.

(If we can determine that this test failure does not demonstrate a significant problem on the new platform, it should be skipped on that platform and the issue can be moved to the backlog.)

CC @golang/release

@aclements
Copy link
Member

@aclements aclements commented Sep 8, 2021

I looked through some of the logs and they all show time (as measured by time.Now().UnixNano()) moving backwards.

What's interesting is they all appear to roll over in the last 8 digits. The more significant digits are the same between the two reads. To me this suggests a shear when reading the time.

1630030642099881100 => 1630030642000853600
1629664923099568500 => 1629664923000568000
1629390290099822500 => 1629390290000990900
1629181133099089200 => 1629181133000075200
1628840582099496300 => 1628840582001301100

But I can't figure out how we would get shear at 8 decimal digits specifically. Time itself is split between seconds and nanoseconds, but nanoseconds are the bottom 9 digits. time.now in runtime/time_windows_arm64.s reads the low 32 bits and high 32 bits of the time separately with no memory barriers (this is the same on all Windows architectures), but those are in units of 100ns, so if that sheared, I would expect it to be at 100<<32 = 429496729600 ns.

@rsc wrote the windows/arm64 time.now. Also cc @zx2c4 .

@aclements
Copy link
Member

@aclements aclements commented Sep 8, 2021

As an experiment, I did the same comparison in hex. There's no obvious roll-over pattern in hex, so this definitely seems to be related to a decimal representation of time.

0x169f083b**935d848c** => 0x169f083b**8d767a60**
0x169dbb9cf**c439974** => 0x169dbb9cf**65cf8c0**
0x169cc1d**601dedfa4** => 0x169cc1d**5fbfad2b4**
0x169c039bd**923bd30** => 0x169c039bd**33ce7c0**
0x169acde1**23c7ed6c** => 0x169acde1**1ded966c**

@aclements
Copy link
Member

@aclements aclements commented Sep 22, 2021

Also cc @bufflig and @alexbrainman for thoughts.

I'm not worried about the test itself, but this seems to indicate a more fundamental issue with reading time on windows/arm64.

@aclements
Copy link
Member

@aclements aclements commented Sep 22, 2021

Actually, it's possible this was caused by #48476, which was fixed three days ago.

@aclements
Copy link
Member

@aclements aclements commented Sep 22, 2021

Nevermind, #48476 only applied to arm32.

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

Successfully merging a pull request may close this issue.

None yet
2 participants