Closed vatsa287 closed 6 months ago
Does it still ICE if you clean the build cache and try again? Might be an incr-comp bug.
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
thread 'rustc' panicked at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/compiler/rustc_serialize/src/opaque.rs:233:42:
range start index 271559 out of range for slice of length 139264
stack backtrace:
0: 0x70840dbd162c - std::backtrace_rs::backtrace::libunwind::trace::ha637c64ce894333a
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/../../backtrace/src/backtrace/libunwind.rs:104:5
1: 0x70840dbd162c - std::backtrace_rs::backtrace::trace_unsynchronized::h47f62dea28e0c88d
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/../../backtrace/src/backtrace/mod.rs:66:5
2: 0x70840dbd162c - std::sys_common::backtrace::_print_fmt::h9eef0abe20ede486
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys_common/backtrace.rs:67:5
3: 0x70840dbd162c - <std::sys_common::backtrace::_print::DisplayBacktrace as core::fmt::Display>::fmt::hed7f999df88cc644
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys_common/backtrace.rs:44:22
4: 0x70840dc24630 - core::fmt::rt::Argument::fmt::h1539a9308b8d058d
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/fmt/rt.rs:142:9
5: 0x70840dc24630 - core::fmt::write::h3a39390d8560d9c9
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/fmt/mod.rs:1120:17
6: 0x70840dbc554f - std::io::Write::write_fmt::h5fc9997dfe05f882
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/io/mod.rs:1762:15
7: 0x70840dbd1414 - std::sys_common::backtrace::_print::h894006fb5c6f3d45
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys_common/backtrace.rs:47:5
8: 0x70840dbd1414 - std::sys_common::backtrace::print::h23a2d212c6fff936
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys_common/backtrace.rs:34:9
9: 0x70840dbd40a7 - std::panicking::default_hook::{{closure}}::h8a1d2ee00185001a
10: 0x70840dbd3e0f - std::panicking::default_hook::h6038f2eba384e475
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:292:9
11: 0x70840a937190 - std[409886f6357001f0]::panicking::update_hook::<alloc[c1b021ad36e35877]::boxed::Box<rustc_driver_impl[7d23c5715ff089db]::install_ice_hook::{closure#0}>>::{closure#0}
12: 0x70840dbd47e8 - <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call::h1f8f335eaa9cfaee
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/boxed.rs:2021:9
13: 0x70840dbd47e8 - std::panicking::rust_panic_with_hook::h2b5517d590cab22e
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:783:13
14: 0x70840dbd453e - std::panicking::begin_panic_handler::{{closure}}::h233112c06e0ef43e
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:657:13
15: 0x70840dbd1af6 - std::sys_common::backtrace::__rust_end_short_backtrace::h6e893f24d7ebbff8
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys_common/backtrace.rs:170:18
16: 0x70840dbd42a2 - rust_begin_unwind
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/panicking.rs:645:5
17: 0x70840dc20d15 - core::panicking::panic_fmt::hbf0e066aabfa482c
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/panicking.rs:72:14
18: 0x70840dc26f62 - core::slice::index::slice_start_index_len_fail_rt::h2cff72a74e55bc89
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/slice/index.rs:52:5
19: 0x70840dc26f62 - core::slice::index::slice_start_index_len_fail::h89a39d0ac724bb0b
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/core/src/slice/index.rs:40:9
20: 0x70840c746011 - <rustc_metadata[21a965c5240b0d]::locator::CrateLocator>::extract_one
21: 0x70840c744d1d - <rustc_metadata[21a965c5240b0d]::locator::CrateLocator>::extract_lib
22: 0x70840c69c5e9 - <rustc_metadata[21a965c5240b0d]::creader::CrateLoader>::load
23: 0x70840c88b690 - <rustc_metadata[21a965c5240b0d]::creader::CrateLoader>::maybe_resolve_crate
24: 0x70840c21765b - <rustc_resolve[ec47402b5e317cbf]::Resolver>::early_resolve_ident_in_lexical_scope
25: 0x70840c2ed787 - <rustc_resolve[ec47402b5e317cbf]::Resolver>::resolve_path_with_ribs
26: 0x70840c6ee6a2 - <rustc_resolve[ec47402b5e317cbf]::Resolver as rustc_expand[76cb781f6d4c8c2e]::base::ResolverExpand>::resolve_imports
27: 0x70840c4ef71a - <rustc_expand[76cb781f6d4c8c2e]::expand::MacroExpander>::fully_expand_fragment
28: 0x70840c372b26 - <rustc_expand[76cb781f6d4c8c2e]::expand::MacroExpander>::expand_crate
29: 0x70840c89bc21 - rustc_interface[fbb0cb4be6c0ba34]::passes::resolver_for_lowering
30: 0x70840c89af89 - rustc_query_impl[664ae873a521fa7c]::plumbing::__rust_begin_short_backtrace::<rustc_query_impl[664ae873a521fa7c]::query_impl::resolver_for_lowering::dynamic_query::{closure#2}::{closure#0}, rustc_middle[aca4860da4e5a967]::query::erase::Erased<[u8; 8usize]>>
31: 0x70840cacead0 - rustc_query_system[b5dcdc06a735d5f1]::query::plumbing::try_execute_query::<rustc_query_impl[664ae873a521fa7c]::DynamicConfig<rustc_query_system[b5dcdc06a735d5f1]::query::caches::SingleCache<rustc_middle[aca4860da4e5a967]::query::erase::Erased<[u8; 8usize]>>, false, false, false>, rustc_query_impl[664ae873a521fa7c]::plumbing::QueryCtxt, true>
32: 0x70840c907891 - rustc_query_impl[664ae873a521fa7c]::query_impl::resolver_for_lowering::get_query_incr::__rust_end_short_backtrace
33: 0x70840ca06e46 - rustc_interface[fbb0cb4be6c0ba34]::interface::run_compiler::<core[21cdcf8e8af4c2d9]::result::Result<(), rustc_span[3d5dc97049ad8d50]::ErrorGuaranteed>, rustc_driver_impl[7d23c5715ff089db]::run_compiler::{closure#1}>::{closure#0}
34: 0x70840ca0215b - std[409886f6357001f0]::sys_common::backtrace::__rust_begin_short_backtrace::<rustc_interface[fbb0cb4be6c0ba34]::util::run_in_thread_with_globals<rustc_interface[fbb0cb4be6c0ba34]::interface::run_compiler<core[21cdcf8e8af4c2d9]::result::Result<(), rustc_span[3d5dc97049ad8d50]::ErrorGuaranteed>, rustc_driver_impl[7d23c5715ff089db]::run_compiler::{closure#1}>::{closure#0}, core[21cdcf8e8af4c2d9]::result::Result<(), rustc_span[3d5dc97049ad8d50]::ErrorGuaranteed>>::{closure#0}::{closure#0}, core[21cdcf8e8af4c2d9]::result::Result<(), rustc_span[3d5dc97049ad8d50]::ErrorGuaranteed>>
35: 0x70840ca01fb3 - <<std[409886f6357001f0]::thread::Builder>::spawn_unchecked_<rustc_interface[fbb0cb4be6c0ba34]::util::run_in_thread_with_globals<rustc_interface[fbb0cb4be6c0ba34]::interface::run_compiler<core[21cdcf8e8af4c2d9]::result::Result<(), rustc_span[3d5dc97049ad8d50]::ErrorGuaranteed>, rustc_driver_impl[7d23c5715ff089db]::run_compiler::{closure#1}>::{closure#0}, core[21cdcf8e8af4c2d9]::result::Result<(), rustc_span[3d5dc97049ad8d50]::ErrorGuaranteed>>::{closure#0}::{closure#0}, core[21cdcf8e8af4c2d9]::result::Result<(), rustc_span[3d5dc97049ad8d50]::ErrorGuaranteed>>::{closure#1} as core[21cdcf8e8af4c2d9]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
36: 0x70840dbde6a5 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::hc7eafaff61e32df9
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/boxed.rs:2007:9
37: 0x70840dbde6a5 - <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once::h6ba4a5de48dd2304
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/boxed.rs:2007:9
38: 0x70840dbde6a5 - std::sys::unix::thread::Thread::new::thread_start::he469335aef763e45
at /rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys/unix/thread.rs:108:17
39: 0x708407caa9eb - <unknown>
40: 0x708407d2e8ac - <unknown>
41: 0x0 - <unknown>
rustc 1.75.0 (82e1608df 2023-12-21)
binary: rustc
commit-hash: 82e1608dfa6e0b5569232559e3d385fea5a93112
commit-date: 2023-12-21
host: x86_64-unknown-linux-gnu
release: 1.75.0
LLVM version: 17.0.6
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
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, 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 rm -rf ~/.cargo/registry/src/
helped with this, thanks! Would be useful to have it in the error itself, if possible
Yeah
rm -rf ~/.cargo/registry/src/
helped with this, thanks! Would be useful to have it in the error itself, if possible
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 -C incremental=[REDACTED]
.
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
@saethlin @jieyouxu Thanks for quick updates.
This issue was solved with cargo clean
.
What bugged me was that this was on a fresh build, with no pre-existing binaries.
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
rm -rf ~/.cargo/registry/src/
helped with this, thanks! Would be useful to have it in the error itself, if possible
Hm, it broke again and removing rm -rf ~/.cargo/registry/src/
doesn't fix it
Hm, it broke again and removing
rm -rf ~/.cargo/registry/src/
doesn't fix it
As saethlin mentioned above, are you sure you're not running out of disk space?
Hm, it broke again and removing
rm -rf ~/.cargo/registry/src/
doesn't fix itAs saethlin mentioned above, are you sure you're not running out of disk space?
Yes, I'm pretty sure. I have ~90 more GiB Also at the bottom of error I have compiler flags included as well, and some other information
note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental=[REDACTED]
note: some of the compiler flags provided by cargo are hidden
query stack during panic:
#0 [resolver_for_lowering] getting the resolver for lowering
end of query stack
Wait, I didn't pick up that you're doing rm -rf ~/.cargo/registry/src/
initially. Doesn't that just remove the cargo registry sources for your dependencies? By clearing the build cache I meant cargo clean
on your project. If you can still produce an ICE after that, then please kindly report that in another issue, as your issue might seem similar to vatsa287's issue, but they don't necessarily have the same root cause.
Wait, I didn't pick up that you're doing
rm -rf ~/.cargo/registry/src/
initially. Doesn't that just remove the cargo registry sources for your dependencies? By clearing the build cache I meantcargo clean
on your project.
Yesterday decided to try clearing registry sources, before cargo clean
, because cargo clean
was not enough. And today, just managed to fix it by clearing cache of sccache
as well. Thanks for quick and helpful responses! Will create new issue if I get this error again
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 https://github.com/rust-lang/rust/pull/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 Ubuntu Give below errors.Version
rustc --version --verbose:
Error output
Error Backtrace