Skip to content

Large allocations in const eval can OOM crash the compiler #79601

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

Closed
oli-obk opened this issue Dec 1, 2020 · 2 comments · Fixed by #86255
Closed

Large allocations in const eval can OOM crash the compiler #79601

oli-obk opened this issue Dec 1, 2020 · 2 comments · Fixed by #86255
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) C-bug Category: This is a bug. I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.

Comments

@oli-obk
Copy link
Contributor

oli-obk commented Dec 1, 2020

I tried this code:

const FOO: () = {
    let x = [0_u8; 1000*1000*1000];  
};

I expected to see this happen: An error about the constant evaluation using more memory than the compiler having available

Instead, this happened: The compiler triggered an abort

Meta

rustc --version --verbose:

1.48.0
Backtrace

I think we'll need to stop using Vec and move to manually using AllocRef::alloc (and maybe Box<[u8]>? in order to allow bubbling up allocation errors during const eval back to the user via error messages.

cc @rust-lang/wg-const-eval

related: #23600

@oli-obk oli-obk added I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics. C-bug Category: This is a bug. A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) labels Dec 1, 2020
@RalfJung
Copy link
Member

RalfJung commented Dec 1, 2020

I think we'll need to stop using Vec and move to manually using AllocRef::alloc (and maybe Box<[u8]>? in order to allow bubbling up allocation errors during const eval back to the user via error messages.

IIRC the plan of the allocator WG was to have a form of Vec::try_reserve that could be used in such situations?
Cc @TimDiekmann @Amanieu

EDIT: seems like such a method actually already exists.

@lcnr
Copy link
Contributor

lcnr commented Dec 1, 2020

even if we use try_reserve here if the allocation is big enough but doesn't quite hit the limit by itself we will end up aborting somewhere else instead. It might make sense to add something like #[const_allocation_size_limit = 1_000_000] which restricts the total size of all allocations during const eval.

syvb added a commit to syvb/rust that referenced this issue Jun 12, 2021
bors added a commit to rust-lang-ci/rust that referenced this issue Jul 4, 2021
…i-obk

Support allocation failures when interpreting MIR

This closes rust-lang#79601 by handling the case where memory allocation fails during MIR interpretation, and translates that failure into an `InterpError`. The error message is "tried to allocate more memory than available to compiler" to make it clear that the memory shortage is happening at compile-time by the compiler itself, and that it is not a runtime issue.

Now that memory allocation can fail, it would be neat if Miri could simulate low-memory devices to make it easy to see how much memory a Rust program needs.

Note that this breaks Miri because it assumes that allocation can never fail.
@bors bors closed this as completed in 524e575 Jul 4, 2021
bjorn3 pushed a commit to bjorn3/rust that referenced this issue Jul 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-eval Area: Constant evaluation, covers all const contexts (static, const fn, ...) C-bug Category: This is a bug. I-crash Issue: The compiler crashes (SIGSEGV, SIGABRT, etc). Use I-ICE instead when the compiler panics.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants