-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disk cache ICE with big array #76037
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) ❄️
P-high
High priority
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
WG-incr-comp
Working group: Incremental compilation
Comments
Spferical
added
C-bug
Category: This is a bug.
I-ICE
Issue: The compiler panicked, giving an Internal Compilation Error (ICE) ❄️
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
labels
Aug 28, 2020
@Spferical do you know if this is still a problem for you? @rustbot claim |
On 1.66.0, I still get an error upon incremental recompilation with the same code:
Backtrace
|
Oh wow I didn't know anyone actually hit this so long ago! I turned this into a much nicer panic a few months ago: #110632 |
3 tasks
github-actions bot
pushed a commit
to rust-lang/miri
that referenced
this issue
Jul 18, 2023
Use u64 for incr comp allocation offsets Fixes rust-lang/rust#76037 Fixes rust-lang/rust#95780 Fixes rust-lang/rust#111613 These issues are all reporting ICEs caused by using `u32` to store offsets to allocations in the incremental compilation cache. This PR aims to lift that limitation by changing the offset type in question to `u64`. There are two perf runs in this PR. The first reports a regression, and the second does not. The changes are the same in both. I rebased the PR then did the second perf run because I noticed that the primary regression in it was very commonly seen in spurious regression reports. I do not know what the perf run will report when this is merged. I would not be surprised to see regression or neutral, but the cachegrind diffs for the regression point at `try_mark_previous_green` which is a common source of inexplicable regressions and I don't think should be perturbed by this PR. I'm not opposed to adding a regression test such as ```rust fn main() { println!("{}", [37; 1 << 30].len()); } ``` But that program takes 1 minute to compile and consumes 4.6 GB of memory then writes that much to disk. Is that a concerning amount of resource use for a test? r? `@nnethercote`
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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) ❄️
P-high
High priority
T-compiler
Relevant to the compiler team, which will review and decide on the PR/issue.
WG-incr-comp
Working group: Incremental compilation
Code
Meta
rustc --version --verbose
:I see similar behavior in stable
1.46.0
:The example always succeeds to compile the first time, but uses a large amount of time and memory.
time cargo build
:Upon incremental re-compilation, I almost always see one of the following errors.
I saw other open issues with a similar error message as the 1.46.0 output below, but in this one the error is affected by the value the array was filled with.
Error output
cargo clean && cargo build && touch src/main.rs && cargo build
:Running sometimes yields a different yet similar error:
On 1.46.0:
Backtrace
On 1.46.0:
The text was updated successfully, but these errors were encountered: