ICE: 'index out of bounds' in on_disk_cache.rs, then double panic 'Illegal read of:' #108481
Assignees
Labels
A-incr-comp
Area: Incremental compilation
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
S-has-mcve
Status: A Minimal Complete and Verifiable Example has been found for this issue
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Comments
kpreid
added
C-bug
|
On looking more closely at the backtrace, it seems that this error results from attempting to load corrupted (truncated) query cache files, and therefore it would be valuable to obtain a trace from the file having been written (assuming that they are truncated due to a panic during write; if they're silently corrupted that's even harder to notice). I will update this issue if I manage to catch such a case. |
|
Looking at the first panic observed since a |
|
I have made some progress on reproducing the problem with a minimal incremental change (but not yet a minimal standalone code sample), and @Nilstrieb expressed some interest in looking at the problem, so I've published branches with the work I have so far. Repro steps:
The second build will ICE. The differences between the two branches are shuffling code between modules, adding a module, and deleting a module; the code in them is as identical as it can be. |
|
Note: I cannot reproduce this ICE on x86_64-unknown-linux-gnu with the latest nightly by default, but backtrace |
|
I've created a new branch which slighly simplifies the diff application: https://github.com/Nilstrieb/all-is-cubes/tree/try (bb8f36b at the time of writing). |
|
I've tried to find out a bit more about this, but didn't get very far. From what I can tell:
The |
|
Maybe |
|
It does indeed have no dependencies. I imagine that this is the culprit: I'm not really up-to-date with query feeding but this looks fishy. When a dep-node has no dependencies, it will trivially evaluate to green. Don't we need at least a dependency on the query that does the feeding? |
|
Given what we've learned about this bug, it's likely that this is purely about incremental compilation cache keying, i.e. neither state of the code is more likely to be miscompiled than the other, right? In other words, I as the author of the original code probably don't need to worry that I'm making my compiled code less reliable if I make the change that caused the ICE, as long as I |
|
Yes, as far as I can tell, this is a bug in incremental compilation's dependency tracking and does not affect non-incremental builds. |
|
Hey, I'm back with a repro! Thanks go out to cargo-minimize, without which I would have never been able to minimize this. A one-command minimization is available at Noratrieb/all-is-cubes@feaf3c0 with
use std::fmt::Debug;
#[derive(Debug)] // I am not able to expand this derive.
pub struct ConstGeneric<const CHUNK_SIZE: usize> {
_p: [(); CHUNK_SIZE],
}
/////// MOVE START
impl<const CHUNK_SIZE: usize> ConstGeneric<CHUNK_SIZE> {}
/////// MOVE ENDRunning diff --git a/src/lib.rs b/src/lib.rs
index 19b10697..c51f498e 100644
--- a/src/lib.rs
+++ b/src/lib.rs
@@ -5,6 +5,4 @@ pub struct ConstGeneric<const CHUNK_SIZE: usize> {
_p: [(); CHUNK_SIZE],
}
-/////// MOVE START
-impl<const CHUNK_SIZE: usize> ConstGeneric<CHUNK_SIZE> {}
/////// MOVE ENDThen running For some strange reason I am unable to reproduce the changes when applying the diff in vscode via WSL. |
Noratrieb
added
the
S-has-mcve
|
I will unassign myself as I mostly assigned myself for the MCVE. |
|
It looks like some things, like lowering to HIR, are run within a The reason seems to be that we set I'll look into fixing this some time this week. |
RalfJung
pushed a commit
to RalfJung/miri
that referenced
this issue
Apr 14, 2023
…jgillot incr.comp.: Make sure dependencies are recorded when feeding queries during eval-always queries. This PR makes sure we don't drop dependency edges when feeding queries during an eval-always query. Background: During eval-always queries, no dependencies are recorded because the system knows to unconditionally re-evaluate them regardless of any actual dependencies. This works fine for these queries themselves but leads to a problem when feeding other queries: When queries are fed, we set up their dependency edges by copying the current set of dependencies of the feeding query. But because this set is empty for eval-always queries, we record no edges at all -- which has the effect that the fed query instances always look "green" to the system, although they should always be "red". The fix is to explicitly add a dependency on the artificial "always red" dep-node when feeding during eval-always queries. Fixes rust-lang/rust#108481 Maybe also fixes issue rust-lang/rust#88488. cc `@jyn514` r? `@cjgillot` or `@oli-obk`
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is one of those ICEs that are terribly hard to minimize because they happen
randomly andcache-dependently,but hopefully the backtraces will be useful[update: see below for repro instructions]. If nothing else, notice that there is a panic while trying to print the query stack; it might be desirable to look into making that not happen so as to be able to get more information.Meta
Occurred while running
cargo checkorcargo clippy.rustc --version --verbose:Error output
Backtrace
@rustbot label +A-incr-comp
The text was updated successfully, but these errors were encountered: