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 fn
which 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 theoom
lang item #51607. The downside is some mandatory space overhead.
Metadata
Metadata
Assignees
Labels
Area: Custom and system allocatorsBlocker: Implemented in the nightly compiler and unstable.Category: An issue tracking the progress of sth. like the implementation of an RFCLibs issues that are tracked on the team's project board.Status: There are blocking design concerns.Status: It's hard to tell what's been done and what hasn't! Someone should do some investigation.Relevant to the language teamRelevant to the library API team, which will review and decide on the PR/issue.Working group: Embedded systemsThis PR / issue is in PFCP or FCP with a disposition to close it.The final comment period is finished for this PR / Issue.