Compiler OOM when creating extremely large array of String using const with const evaluation
#94643
Comments
|
The fix here might be similar to the fix in #86255? Try and reserve the |
|
Cc @rust-lang/wg-const-eval |
oli-obk
added
the
I-crash
|
Triage: This seems fixed now: $ cat src/main.rs
pub fn main() {
const S: String = String::new();
let _ = [S; usize::MAX >> 5];
}
$ cargo build
Compiling minimal v0.1.0 (/home/martin/src/bin)
error: values of the type `[String; 576460752303423487]` are too big for the current architecture
error: could not compile `minimal` (bin "minimal") due to 1 previous errorI'm going to assume a regression test has been added when this was fixed, because I would be very surprised if that wasn't the case. Closing. |
|
I think that just indicates that we now properly skip const-eval if the type is truly unrepresentable. But for a type that's big but within the size limit, I don't think anything got fixed here. Should be easy to reproduce by making the array size smaller until the "too big for the current architecture" error disappears. |
|
Hm... pub fn other() {
const S: String = String::new();
let _ = [S; usize::MAX >> 22];
}
fn main() {
other();
}does not give any error, and it compiles fine. (The binary it produces gives a stack overflow, but that is to be expected.) If rustc truly was trying to actually allocate that many I'll try bisecting this later and seeing what caused this to work, and if it was intentionally done or if it's just work that happened to be skipped. |
|
unfortunately, was fixed quite a while ago. I'll go through these later, it might be pretty obvious which one it is (i hope |
|
Oh right, this isn't actually a huge const, just a huge array of consts. Still, there may or may not have been a regression test added. |
RalfJung
added
the
E-needs-test
|
#109008 looks the most relevant here in particular, the regression test there is: const SZ: usize = 64_000_000;
type BigDrop = [String; SZ];
fn f(_dropme: BigDrop) {}
fn f2(_moveme: BigDrop) -> String {
let [a, ..] = _moveme;
a
}
fn main() {
f(std::array::from_fn(|_| String::new()));
f2(std::array::from_fn(|_| String::new()));
}is probably the issue that was being ran into here. (I think this issue is a dupe of #109004). |
|
Ah, yes that looks very similar. Thanks for digging this out! |
I tried this code:
I expected to see this happen: Either an error about the value being too large for the current architecture, or nothing (because errors about too large arrays don't seem to happen for values bound to
_)Instead, this happened:
# rustc main.rs memory allocation of 13835058055282163688 bytes failed zsh: IOT instruction (core dumped) rustc main.rsMeta
rustc --version --verbose:Valgrind with
trace-children=yesgives me the following location for the errorBacktrace
Which I traced down to probably this line. I'm assuming
sizeis the array size here, but I have not verified that.rust/compiler/rustc_mir_dataflow/src/elaborate_drops.rs
Lines 737 to 751 in c8a49fc
The text was updated successfully, but these errors were encountered: