-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
thread rustc panicked: range start index 35911 out of range for slice of length 16384 #121973
Comments
Does it still ICE if you clean the build cache and try again? Might be an incr-comp bug. |
Just got similar error with fresh build, noticed this issue is fresh, so maybe it is related. Will post my error and backtrace as well Error output
Error backtrace
Version
|
Yeah, unfortunately if it's an incr-comp bug, sometimes yeeting the build cache will make it magically go away and then we can't reproduce it. Does your build still ICE if you yeet the build cache and try building again? |
Yeah |
The idea is that we don't have this in the error itself, because we want people to report incr-comp bugs. Sometimes a bug can also seem like incr-comp bugs but are in other areas, it's hard to tell without having a repro + backtrace. |
This is not an incremental compilation bug. I know that in this case because at the bottom of an ICE we print the compiler flags and there's no But more broadly, please read the Zulip topic I started here: https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/Out-of-disk.20issues.20are.20easy.20to.20confuse.20with.20incr.20comp |
Hm, it broke again and removing |
As saethlin mentioned above, are you sure you're not running out of disk space? |
Yes, I'm pretty sure. I have ~90 more GiB
|
Wait, I didn't pick up that you're doing |
Yesterday decided to try clearing registry sources, before |
The root problem here is that you have/had a truncated rmeta file. In general I think that's most commonly caused by running out of disk, but the output system in rustc (is supposed to) stop trying to write if in I/O error is encountered, but continue compilation as if nothing is wrong until we would finalize the output file, and then only then report an error. One of the problems I've merged fixes for was that the compiler would report success when actually it encountered an I/O error and stopped output. I'd expect that under such circumstances, a caching system like sccache would then cache a broken build artifact. That problem exists in 1.75, the version you are using. This whole system around I/O errors was quite broken for many releases, but in 1.77 (will be stable in 16 days) it finally passes a basic simulation of a spuriously-failing disk. |
I think the root cause of this issue was rustc incorrectly handling/reporting I/O errors. I've landed a number of PRs to address the problem; the most recent of those is #119510 which is now part of the latest stable toolchain, 1.77. Therefore, even though I have not reproduced exactly what you've reported here, I'm going to close this because I am reasonably confident that this bug is now fixed on stable. Of course it is possible that I am wrong and the bug you've reported here is not fixed. If you happen to run into problems like this in 1.77 or later please do not hesitate to open a new issue. |
Compiling with
cargo build --profile=production --features=runtime-benchmarks
in UbuntuGive below errors.
Version
rustc --version --verbose:
Error output
Error Backtrace
The text was updated successfully, but these errors were encountered: