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: negative duration panic in timeHistogram.record #43328

Closed
mknyszek opened this issue Dec 22, 2020 · 4 comments
Closed

runtime: negative duration panic in timeHistogram.record #43328

mknyszek opened this issue Dec 22, 2020 · 4 comments
Assignees
Milestone

Comments

@mknyszek
Copy link
Contributor

@mknyszek mknyszek commented Dec 22, 2020

It's possible sometimes for timeHistogram to get a negative duration either due to a platform bug or surprising time semantics on a given platform.

Notably, this could happen when running under gVisor, where, for efficiency, gVisor provides its own VDSO for acquiring the current monotonic time, but falls back on a different clock if the system clock is wildly in error (https://github.com/google/gvisor/blob/master/vdso/vdso_time.cc#L149).

The result is a panic that can't be worked around. For resiliency's sake, timeHistogram should just accept negative durations and record them.

@mknyszek mknyszek added this to the Go1.16 milestone Dec 22, 2020
@mknyszek mknyszek self-assigned this Dec 22, 2020
@gopherbot

This comment has been hidden.

@gopherbot
Copy link

@gopherbot gopherbot commented Dec 22, 2020

Change https://golang.org/cl/279468 mentions this issue: runtime: shift timeHistogram buckets and allow negative durations

@dmitshur
Copy link
Contributor

@dmitshur dmitshur commented Dec 23, 2020

One test failure where I saw this recently is openbsd-arm64-jsing at 740851bacafd8e47b9a6ce0cd8fa8e05506a7382.

@gopherbot gopherbot closed this in b116404 Dec 23, 2020
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
4 participants