-
Couldn't load subscription status.
- Fork 13.9k
Description
This attribute is mandatory when using the alloc crate without the std crate. It is used like this:
#[alloc_error_handler]
fn foo(_: core::alloc::Layout) -> ! {
// …
}Implementation PR: #52191
Blocking issues
- Adding #[track_caller] on #[alloc_error_handler] seems to cause undefined behavior #83430
- Who is responsible for preventing reentrancy issues through the allocator? unsafe-code-guidelines#506
- alloc_error_handler can be an
unsafe fnwhich is then unsoundly invoked #134225 - The combination of alloc_error_handler and target_features_11 is unsound #134234
Original issue:
In a no_std program or staticlib, linking to the alloc crate may cause this error:
error: language item required, but not found: `oom`
This is fixed by providing the oom lang item, which is is normally provided by the std crate (where it calls a dynamically-settable hook #51245, then aborts). This is called by alloc::alloc::handle_alloc_error (which is called by Vec and others on memory allocation failure).
#![feature(lang_items)]
#[lang = "oom"]
extern fn foo(_: core::alloc::Layout) -> ! {
// example implementation based on libc
extern "C" { fn abort() -> !; }
unsafe { abort() }
}However, defining a lang item is an unstable feature.
Possible solutions include:
- Add and stabilize a dedicated attribute similar to the
#[panic_implementation]attribute:
#[alloc_error_handler]
fn foo(_: core::alloc::Layout) -> ! {
// …
}The downside is that this is one more mandatory hoop to jump through for no_std program that would have been fine with a default hook that aborts.
Movestd’s dynamically-settable hook intoalloc: Move OOM handling to liballoc and remove theoomlang item #51607. The downside is some mandatory space overhead.