ICE rustc 1.26.2 'specified instant was later than self' #51648
Comments
estebank
added
the
I-ICE
|
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 |
kennytm
added
O-windows
|
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. |
|
We're seeing this frequently |
|
Another instance of this issue happening: |
|
@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). |
|
@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
|
|
@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; |
|
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. |
|
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 |
|
I would like to put that code behind a |
|
It's also worth pointing out that the +/- one tick is in theroy handled here, regardless of where it happens or not. |
|
@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? |
|
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. |
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
|
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. |
|
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
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
Noratrieb
added
O-x86_32
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:
The text was updated successfully, but these errors were encountered: