Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upICE rustc 1.26.2 'specified instant was later than self' #51648
Comments
This comment has been minimized.
This comment has been minimized.
|
This error has happened again twice in the past 2 days on our build machines. We are now on Stable 1.27.0. thread 'main' panicked at 'specified instant was later than self', libcore\option.rs:914:5 error: internal compiler error: unexpected panic note: rustc 1.27.0 (3eda71b 2018-06-19) running on i686-pc-windows-msvc note: compiler flags: -C opt-level=3 --crate-type lib |
This comment has been minimized.
This comment has been minimized.
|
Regarding uptimes: I will try to set up a timing script to get a more precise time between compiler errors, but these numbers are ballpark. |
This comment has been minimized.
This comment has been minimized.
|
We're seeing this frequently
|
This comment has been minimized.
This comment has been minimized.
|
Another instance of this issue happening:
|
This comment has been minimized.
This comment has been minimized.
|
@wesleywiser, might this have to do with the self-profiler? It looks like timing on Windows is flaky (maybe it's not using the high-resolution timer by default?). Or there's a bug in the timing code? If it's a flaky timer, it should be easy to not panic (and instead just record a zero-length interval). |
This comment has been minimized.
This comment has been minimized.
|
@michaelwoerister Yes, it looks like the issue is this line in the self profiler: rust/src/librustc/util/profiling.rs Line 200 in 289ad6e What's interesting is that the docs for
|
This comment has been minimized.
This comment has been minimized.
|
@wesleywiser Yes, it certainly looks that way. Might be a bug in the Windows implementation for this method (@rust-lang/libs). If that turns out hard to fix, we might have to work around it. Something like: let now = Instant::now();
let elapsed = if self.current_timer >= now {
Duration::new(0,0)
} else {
self.current_timer.elapsed()
};
self.current_timer = now; |
This comment has been minimized.
This comment has been minimized.
|
While @wesleywiser want to take a look at implementing a work-around in the compiler? We should also fill a separate issue for T-libs. |
This comment has been minimized.
This comment has been minimized.
|
rust/src/libstd/sys/windows/time.rs Lines 45 to 51 in 93fa2d7 https://msdn.microsoft.com/en-us/library/windows/desktop/ms644904(v=vs.85).aspx links to https://docs.microsoft.com/en-us/windows/desktop/SysInfo/acquiring-high-resolution-time-stamps which says:
Which suggests this panic should not happen. But also:
Was |
This comment has been minimized.
This comment has been minimized.
|
I would like to put that code behind a |
This comment has been minimized.
This comment has been minimized.
|
It's also worth pointing out that the +/- one tick is in theroy handled here, regardless of where it happens or not. |
This comment has been minimized.
This comment has been minimized.
|
@michaelwoerister That seems reasonable to me. @nagisa Yes, I'll work on that today if I get some time around the holiday. I think the best thing would be a two-pronged approach:
@estebank Agreed. Will do. @alexcrichton Interesting. Perhaps the delta is greater than 1 tick for some reason? |
This comment has been minimized.
This comment has been minimized.
|
I'm glad to see there's a potential fix! For what it's worth this seems to be very hardware dependent: After moving to a t2.2xlarge AWS instance the problem was still happening, but since upgrading to t3.2xlarge, the problem has not recurred. |
Related to rust-lang#51648
On Windows, the high-resolution timestamp api doesn't seem to always be monotonic. This can cause panics when the self-profiler uses the `Instant` api to find elapsed time. Work around this by detecting the case where now is less than the start time and just use 0 elapsed ticks as the measurement. Fixes rust-lang#51648
On Windows, the high-resolution timestamp api doesn't seem to always be monotonic. This can cause panics when the self-profiler uses the `Instant` api to find elapsed time. Work around this by detecting the case where now is less than the start time and just use 0 elapsed ticks as the measurement. Fixes rust-lang#51648
On Windows, the high-resolution timestamp api doesn't seem to always be monotonic. This can cause panics when the self-profiler uses the `Instant` api to find elapsed time. Work around this by detecting the case where now is less than the start time and just use 0 elapsed ticks as the measurement. Fixes rust-lang#51648
…ws, r=estebank Fix self profiler ICE on Windows Fixes rust-lang#51648
This comment has been minimized.
This comment has been minimized.
|
I guess there's still a question for @rust-lang/libs: should we pursue a fix or change in in the I left a comment here with some additional findings. This doesn't appear to be strictly a Windows issue. For example, #49281 shows the same issue on Linux/arm64 and #48514 shows the same issue on OpenBSD. |
This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations, but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in rust-lang#56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory, returning that instead of the OS looks like it's moving backwards. Closes rust-lang#48514 Closes rust-lang#49281 cc rust-lang#51648 cc rust-lang#56560 Closes rust-lang#56612 Closes rust-lang#56940
This comment has been minimized.
This comment has been minimized.
|
Oh right yeah thanks for the prod @wesleywiser, I've opened #56988 as it seems like the "best" way to go from here |
This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations, but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in rust-lang#56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory, returning that instead of the OS looks like it's moving backwards. Closes rust-lang#48514 Closes rust-lang#49281 cc rust-lang#51648 cc rust-lang#56560 Closes rust-lang#56612 Closes rust-lang#56940
This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations, but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in rust-lang#56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory, returning that instead of the OS looks like it's moving backwards. Closes rust-lang#48514 Closes rust-lang#49281 cc rust-lang#51648 cc rust-lang#56560 Closes rust-lang#56612 Closes rust-lang#56940
std: Force `Instant::now()` to be monotonic This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations, but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in #56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory, returning that instead of the OS looks like it's moving backwards. Closes #48514 Closes #49281 cc #51648 cc #56560 Closes #56612 Closes #56940
This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations, but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in rust-lang#56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory, returning that instead of the OS looks like it's moving backwards. Closes rust-lang#48514 Closes rust-lang#49281 cc rust-lang#51648 cc rust-lang#56560 Closes rust-lang#56612 Closes rust-lang#56940
std: Force `Instant::now()` to be monotonic This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations, but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in #56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory, returning that instead of the OS looks like it's moving backwards. Closes #48514 Closes #49281 cc #51648 cc #56560 Closes #56612 Closes #56940
std: Force `Instant::now()` to be monotonic This commit is an attempt to force `Instant::now` to be monotonic through any means possible. We tried relying on OS/hardware/clock implementations, but those seem buggy enough that we can't rely on them in practice. This commit implements the same hammer Firefox recently implemented (noted in #56612) which is to just keep whatever the lastest `Instant::now()` return value was in memory, returning that instead of the OS looks like it's moving backwards. Closes #48514 Closes #49281 cc #51648 cc #56560 Closes #56612 Closes #56940
After ~2 weeks of continuously building our project without fail, our Windows build machines (2 of them) began throwing an error of this kind, while building dependencies:
Each time this failure occurred it was on a different dependency of the project. It's also worth noting that this failure did not occur on every build, but it was very frequent. The failure occurs using both
i686-pc-windows-msvcandx86_64-pc-windows-msvc.A very similar issue was reported in rustc 1.23.0: #47684
Restarting the affected build machines seems to have stopped the issue from occurring, at least temporarily.
If there's anything I can do to help diagnose/solve this problem, I'm eager to jump in.
Meta
rustc --version --verbose:rustc 1.26.2 (594fb25 2018-06-01)
binary: rustc
commit-hash: 594fb25
commit-date: 2018-06-01
host: i686-pc-windows-msvc
release: 1.26.2
LLVM version: 6.0
Backtrace:
and the relevant output of systeminfo: