ICE: "no entry found for key" while building stage0 tools #88488
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) ❄️
regression-from-stable-to-beta
Performance or correctness regression from stable to beta.
T-bootstrap
Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap)
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
Milestone
Comments
yoshuawuyts
added
C-bug
jyn514
changed the title
|
It looks like old incremental compilation data is getting reused. I believe that this should be fixed by #86641. In the meantime, running |
camelid
added
T-bootstrap
|
Duplicate of #76720. |
|
This is not actually a duplicate. This happens in stage0, not stage1, so it's not related to sharing the version string between different dev builds. It might be the case that we're not clearing the cache when we update the beta compiler, but that will have a different fix and should be tracked separately. (It happened to me this morning) backtrace |
jyn514
changed the title
jyn514
changed the title
|
The strange thing to me is that we shouldn't need to clear the stage0 cache - beta should just be ignoring incremental artifacts that don't match the version hash. @cjgillot @michaelwoerister do you know what could be going on here? |
|
I do think this is a purely incremental bug because |
|
@jyn514, it looks you are able to reproduce this with a current toolchain. Can you provide some instructions on how to trigger the ICE? |
|
@michaelwoerister unfortunately I deleted the directory and didn't record the steps to reproduce the error :( but @BoxyUwU managed to reproduce a similar error by checking out the first commit after the 1.70 version bump, running |
|
Thanks, @jyn514, I'll give that a try. |
|
@michaelwoerister I ran into this again today. Here are the replication steps: rm -rf build
echo 'profile = "compiler"
changelog-seen = 2
[rust]
codegen-backends = ["cranelift"]' > config.toml
git checkout 9a24e2fee95 # might need to fetch from my remote: https://github.com/jyn514/rust/commit/9a24e2fee959fa9a7c3493489dba0223bfbc8928
x build --stage 0 rustc_codegen_cranelift
git checkout 2d429f3064cb67710fe64dee293329089871d92b
x build --stage 0 rustc_codegen_cranelift |
|
... apparently that replicated the error the very first time I did it and then never again 🤦 maybe the second commit was jyn514@a67cb7e? |
|
ok, this actually replicates it: backtrace |
|
#108481 looks related. |
Nice! I reserved some time to take a look at this later this week. |
|
Update: #108481 might indeed be the same issue and I spent most of yesterday finding out more about that. The issue seems to be caused by (sometimes) not recording dependency edges for query results that are directly fed. However, that means that #108481 is not the same as the original issue reported by Yosh because query feeding was only implemented a few months ago. It's unclear if the original issue still exists. |
cc @oli-obk |
bors
added a commit
to rust-lang-ci/rust
that referenced
this issue
Apr 12, 2023
…ways, r=cjgillot 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#108481 Maybe also fixes issue rust-lang#88488. cc `@jyn514` r? `@cjgillot` or `@oli-obk`
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`
|
someone on discord ran into a similar bug today: |
|
ran into the same thing myself |
|
cc @Mark-Simulacrum this is likely a real regression that's going to end up in 1.71 - unclear which PR caused it so probably not much to do at this point but thought you'd want to know since the release is going out soon |
Mark-Simulacrum
added
the
regression-from-stable-to-beta
rustbot
added
the
I-prioritize
|
Tagging for prioritization. It's not clear to me how impactful this is; I know I've seen and heard about other(?) incremental problems in 1.70 as well -- I think there's been some issues filed. Unfortunately I don't think we've found solutions that eliminate the problem at the root so just need to hope we don't introduce new ones :/ |
I wrote a script based on this statement; intending to run a #!/usr/bin/env bash
set -e
./x.py clean
git checkout $(git rev-list 1.70.0..master -n 1)
./x.py build --stage 1 rustdoc
git checkout $BISECT_HEAD
./x.py build --stage 1 rustdoc |
|
yes, sorry - there are several issues mixed into the history here and not all of them are the same. the one that's going to land in 1.71 is #112700, which no one has been able to reliably reproduce. the one boxy ran into was likely fixed by #109935 and no longer reproduces on master. make sure that you do not rebase over any version bump. if the stage0 compiler changes, your testing is invalid (because they just won't read the same metadata files). |
|
If all issues mixed in here are tracked elsewhere cleanly, perhaps it makes sense to close this one? |
apiraino
removed
the
I-prioritize
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Checked out the latest version of the compiler today to write a patch, but ran into an ICE when doing
py check. I haven't changed anything recently, so not sure what's causing this.Code
Compiling the compiler at commit 13edc17
Meta
rustc --version --verbose:Error output
Backtrace
The text was updated successfully, but these errors were encountered: