Open BobG1983 opened 2 weeks ago
I just got a very similar ICE while compiling a proprietary codebase
Running the build again did not hit the same error.
Ditto, similar ICE compiling a proprietary codebase. This was on CI. Rerunning on the same commit then succeeded.
I got an ICE from the OP's code when building tests twice on x86_64-pc-windows-msvc with rustc 1.81.0-nightly (cc8da78a0 2024-07-04):
Weirdly, I can't repro:
rustc 1.81.0-nightly (c1b336cb6 2024-06-21)
: cargo +nightly test
twice, no repro
rustc 1.81.0-nightly (cc8da78a0 2024-07-04)
: cargo +nightly test
twice, no repro
rustc 1.81.0-nightly (cc8da78a0 2024-07-04)
binary: rustc
commit-hash: cc8da78a036dc3c15c35a97651b02af9a6d30c1e
commit-date: 2024-07-04
host: x86_64-pc-windows-msvc
release: 1.81.0-nightly
LLVM version: 18.1.7
I did have to force it to rebuild by touching a file.
I did have to force it to rebuild by touching a file.
Thanks, that does it for me too:
I've minimized this as much as I can. It's quite small now, but still requires two crates and for some reason a path dependency doesn't work. https://github.com/saethlin/rantz_random
The main crate is
pub fn random() {
fastrand::bool()
}
pub fn seed() {
fastrand::seed();
}
And the fastrand
dependency is
std::thread_local! {
static RNG: () = ();
}
#[inline]
fn with_rng(f: impl FnOnce()) {
RNG.with(|_| {
f()
})
}
#[inline]
pub fn seed() {
with_rng(|| {});
}
#[inline]
pub fn bool() {
with_rng(|| {})
}
And you must have:
-Zthreads=0
(probably any value other than can work)-Copt-level=2
-j2
(any number of jobs other than 1, so the default on multi-CPU systems is fine).For me, the build ICEs about 1 in every 10 compilations, but it is of course random.
searched nightlies: from nightly-2024-01-01 to nightly-2024-07-04 regressed nightly: nightly-2024-06-05 searched commit range: https://github.com/rust-lang/rust/compare/7c52d2db6348b038276198e88a835125849f322e...a330e49593ee890f9197727a3a558b6e6b37f843 regressed commit: https://github.com/rust-lang/rust/commit/27529d5c2526eab5aa03d765426c44ea55c5d269
So that's https://github.com/rust-lang/rust/pull/125525 which is just a rewrite of the TLS implementation. All that tells me is that the compiler bug here predates that PR.
Hunh, the ICE goes away if I add -j1
to the cargo build
invocation... That seems bad.
We are interning alloc1
with bytes that are a pointer to alloc2
then trying to re-intern alloc1
, but this time it's a pointer to alloc3
. But why...
Ah! Turning off GVN makes the reproducer go away. That explains why this is being reported now.
The root cause maybe that alloc id creation is untracked in incremental and only kept sane by stable hashing the GlobalAlloc instead of the raw index. Maybe there are some issues where we somehow leak the actual index
I've further minimized the library crate to this:
const RNG: fn() = || {};
fn with_rng() {
let _x = &RNG;
}
pub fn seed() {
with_rng();
}
pub fn bool() {
with_rng();
}
This bisects to a handful of different commits, depending on what I set the start of the range to. I suspect that's because the reproducer relies on MIR inlining, and sometimes the critical inlining of with_rng()
into seed
and bool
is blocked by query cycle avoidance.
@oli-obk I think this is more likely a race condition causing the incremental compilation decoding process to enter an invalid state. Of course I'm no expert on the code here, but the fact that triggering the crash requires multiple -Zthreads
and multiple Cargo --jobs
seems to point that way. Though I cannot explain why multiple compilers running at once would be relevant.
In a successful build, we decode alloc1
twice, and both times it contains a pointer to alloc2
.
In a crashing build, we decode alloc1
twice, and the first time it contains a pointer to alloc2
and the second time, it contains a pointer to alloc3
. In addition, every time we hit this code path, we crash:
https://github.com/rust-lang/rust/blob/0ca92de4733bf31262200c6d37e722f534cef4bc/compiler/rustc_middle/src/mir/interpret/mod.rs#L256-L258
... and I've been unable to find any other workload that tickles that line of code.
So based on the available evidence, it looks like this whole concurrent decoding system just doesn't work.
Yes I realize I'm making the very brave assertion that this PR from 6 years ago is buggy: https://github.com/rust-lang/rust/pull/51060
I created this PR: https://github.com/rust-lang/rust/pull/127442 which moves the lock scope so that instead of permitting racy decoding, the lock prevents racy decoding. This PR fixes the ICE, but I feel like it breaks the original design of the system. But also it seems to be perf-neutral.
Repro:
Rustc Version: rustc 1.81.0-nightly (59e2c01c2 2024-06-17) Toolchain: nightly-x86_64-pc-windows-msvc
What I did: Clone https://www.github.com/BobG1983/rantz_random.git run cargo test run cargo test again.
Issue:
The compiler panics with the following output: