ICE: index out of bounds in cg_ssa/src/back/archive.rs #129557
Comments
rogelx
added
C-bug
rustbot
added
the
needs-triage
|
@rogelx How did you run into this ICE? What were you compiling? |
saethlin
removed
the
needs-triage
|
a kvm project using menflow @saethlin |
|
Compiling bit-vec v0.6.3 error: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md note: please make sure that you have updated to the latest nightly note: please attach the file at /home/jason/.cargo/registry/src/mirrors.aliyun.com-8754fae0eb2f08f1/v8-0.103.0/rustc-ice-2024-08-25T09_59_20-200180.txt to your bug report note: compiler flags: --crate-type lib -C opt-level=3 -C embed-bitcode=no -C linker=clang -C strip=debuginfo -C link-arg=-fuse-ld=lld -Z share-generics=y -Z threads=0 -Z macro-backtrace note: some of the compiler flags provided by cargo are hidden query stack during panic: |
|
I've just hit this on 1.82.0 stable. Interestingly also while building the |
saethlin
changed the title
|
Just ran into this same issue while building thread 'rustc' panicked at compiler/rustc_codegen_ssa/src/back/archive.rs:472:29:
range end index 50665808 out of range for slice of length 50659328
stack backtrace:
0: 0x7f3bc893aca5 - std::backtrace::Backtrace::create::h49cf04578963fdc5
1: 0x7f3bc6ebce85 - std::backtrace::Backtrace::force_capture::hd4872c7bc65cde41
2: 0x7f3bc605200e - std[fac44eaeb111bcc8]::panicking::update_hook::<alloc[66489a0f9c76ca63]::boxed::Box<rustc_driver_impl[1ee6f045412d773c]::install_ice_hook::{closure#1}>>::{closure#0}
3: 0x7f3bc6ed5253 - std::panicking::rust_panic_with_hook::h1cf1663d92a293a0
4: 0x7f3bc6ed4f4a - std::panicking::begin_panic_handler::{{closure}}::had554dcf018971db
5: 0x7f3bc6ed2ae9 - std::sys::backtrace::__rust_end_short_backtrace::hefbe23e83e53be67
6: 0x7f3bc6ed4c0d - rust_begin_unwind
7: 0x7f3bc3b9cb40 - core::panicking::panic_fmt::haccb7628e277b865
8: 0x7f3bc5a872f7 - core::slice::index::slice_end_index_len_fail::do_panic::runtime::h464f069a5b86dbfe
9: 0x7f3bc52782da - core::slice::index::slice_end_index_len_fail::h1fa0fb4a7587ffdc
10: 0x7f3bc834da24 - <rustc_codegen_ssa[d8b4a3d99ad9c652]::back::archive::ArArchiveBuilder as rustc_codegen_ssa[d8b4a3d99ad9c652]::back::archive::ArchiveBuilder>::build
11: 0x7f3bc86000a3 - rustc_codegen_ssa[d8b4a3d99ad9c652]::back::link::link_binary
12: 0x7f3bc85ff41e - <rustc_interface[a5b8f6a3ca67129a]::queries::Linker>::link
13: 0x7f3bc8511864 - rustc_interface[a5b8f6a3ca67129a]::interface::run_compiler::<(), rustc_driver_impl[1ee6f045412d773c]::run_compiler::{closure#0}>::{closure#1}
14: 0x7f3bc8414c07 - std[fac44eaeb111bcc8]::sys::backtrace::__rust_begin_short_backtrace::<rustc_interface[a5b8f6a3ca67129a]::util::run_in_thread_with_globals<rustc_interface[a5b8f6a3ca67129a]::util::run_in_thread_pool_with_globals<rustc_interface[a5b8f6a3ca67129a]::interface::run_compiler<(), rustc_driver_impl[1ee6f045412d773c]::run_compiler::{closure#0}>::{closure#1}, ()>::{closure#0}, ()>::{closure#0}::{closure#0}, ()>
15: 0x7f3bc84150a4 - <<std[fac44eaeb111bcc8]::thread::Builder>::spawn_unchecked_<rustc_interface[a5b8f6a3ca67129a]::util::run_in_thread_with_globals<rustc_interface[a5b8f6a3ca67129a]::util::run_in_thread_pool_with_globals<rustc_interface[a5b8f6a3ca67129a]::interface::run_compiler<(), rustc_driver_impl[1ee6f045412d773c]::run_compiler::{closure#0}>::{closure#1}, ()>::{closure#0}, ()>::{closure#0}::{closure#0}, ()>::{closure#1} as core[249175d58a5edd5c]::ops::function::FnOnce<()>>::call_once::{shim:vtable#0}
16: 0x7f3bc8416681 - std::sys::pal::unix::thread::Thread::new::thread_start::h1f4f8d3a2ffc672f
17: 0x7f3bc9bb51c4 - start_thread
at ./nptl/pthread_create.c:442:8
18: 0x7f3bc9c3585c - clone3
at ./misc/../sysdeps/unix/sysv/linux/x86_64/clone3.S:81:0
19: 0x0 - <unknown>
rustc version: 1.86.0-nightly (243d2ca4d 2025-01-06)
platform: x86_64-unknown-linux-gnu% [package]
name = "sample"
version = "0.1.0"
edition = "2021"
[dependencies]
clap = "4.5.23"
divan = "0.1.17"
serde = "1.0.217"
serde_json = "1.0.135"
v8 = "130.0.6"
wasm-bindgen = "0.2.99"
wasm-bindgen-test = "0.3.49"
web-sys = { version = "0.3.76", features = ["Window", "Performance"] }
[build-dependencies]
cargo = "0.84.0"
[features]
default = ["core"]
core = [] # Core functionality
test = ["core"] # Testing infrastructure
bench = ["core"] # Benchmarking infrastructure
v8 = [] # V8 WASM target support |
|
I'm pretty sure that crash is caused by an archive file being overwritten or modified while the compiler is interacting with it. The reason the crash looks funny is that we're The fact that we are using mmap makes this extra-bad, but I'm pretty confident that using normal file reads would just make the compiler slower and no more correct. If the compiler is being fed a file that's being modified while the compiler is running, there's not a correct thing for the compiler to do. I suspect that this is a subtle bug in |
workingjubilee
added
C-gub
|
Closing as user bug caused by build script and thus not actionable here. @devsnek Feel free to prove me wrong, if you like. |
|
Yeah I have a feeling it's an obscure edge case. The v8 library is awesome, but the build scripts... there's all sorts of weirdness, including a Python script to download precompiled releases. I'll re-open this again in denoland/rusty_v8#1681 . Thanks both! |
|
@saethlin or @workingjubilee could you expand a bit on the implications here? I'm happy to accept that this awful build script is causing issues, but based on what's been described I'm wondering if I have a misunderstanding of what's expected of build scripts at a high level. Does rustc+cargo attempt to interact with archive files while build scripts are still running? |
|
@devsnek A lot of invocations of the compiler are concurrent. The compiler and cargo try to work out their own file-locking protocol which a build script isn't necessarily participating in. Many executions of the compiler are reading the output of previous executions, and this output is trusted to have remained in its original form. |
|
I suspect that based on the kinds of descriptions here that this is related to colliding incremental builds. What jumps out at me is that you are writing to
|
|
Hm. If it is incremental, then shouldn't we be validating the hashes...? @devsnek Can you describe, at a higher-level, what that build script does? there's uh,,, |
The hash of what though. This build script is scribbling a file it's acquired from elsewhere into a directory that's shared between sessions. |
|
...that is a very good question. |
|
I am 100% certain that a build script that was dead-set on corrupting our build state can do so, I'm just wondering if there's a way to cheaply tell build scripts that do so without any malice aforethought "hey, I'm compiling here!" |
very high level: v8's has a custom build system called GN which is like a trillion lines of python. so the build.rs script attempts to set up gn and its dependencies and then run a build. It does this above the script can also download a prebuilt binary instead of building one from scratch. it has to manually download it because they are too large for crates.io. the script also uses its own lockfile, because we had observed that cargo can sometimes perform tasks on different targets in parallel (for example when running there is also a bindgen step to generate bindings from v8 headers, but this only generates a .rs file so i imagine its not the cause of any issues here. so within a file lock, it will either:
So I guess with all this in mind, I guess if you had this scenario: cargo task a: in some phase that is after running build scripts cargo task a could fail. but i assumed that this wouldn't be possible because of cargo's own locks. |
|
I uh, would not be surprised if cargo doesn't try to protect itself against a build script that is, in a formal sense, misbehaving (writing outside the prescribed output directories), and thus you managed to "bypass" the locks... because there wasn't a lock against the thing that shouldn't happen. |
|
@devsnek Could these problems be sidestepped if the prebuild was available via crates? It seems there's an established process to request custom crate limits as per rust-lang/crates.io#195, but I'm assuming it's not that simple. I should probably become more familiar with rusty_v8 build scripts! |
Code
<code>Meta
rustc --version --verbose:Error output
Backtrace
The text was updated successfully, but these errors were encountered: