Repository navigation
Tracking issue for the #[alloc_error_handler] attribute (for no_std + liballoc) #51540
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
-
#[alloc_error_handler]must not unwind. So we have to either make this a safety requirement or catch unwinding ourselves. - 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.
Activity
SimonSapin commentedon Jun 13, 2018
Better idea: remove the lang item and move all of OOM handling to liballoc, except for the default hook that prints to stderr. Have compiler magic similar to that of
#[global_allocator]that uses the printing default hook whenstdis linked, or a no-op default hook otherwise.glandium commentedon Jun 13, 2018
Bikeshedding on
oomrenaming:alloc_errorwould be shorter.SimonSapin commentedon Jun 14, 2018
I forgot to link #51543, which does indeed use
alloc_error.SimonSapin commentedon Jun 29, 2018
@japaric, @glandium, @Amanieu I’ve updated the the issue description here with arguments from #51607 and rust-lang/rfcs#2480 and to list two alternatives.
157 remaining items
embedded: Remove error handler
Merge #1814: embedded: Remove error handler
Auto merge of rust-lang#109507 - Amanieu:panic-oom-payload, r=davidtwco
Auto merge of rust-lang#109507 - Amanieu:panic-oom-payload, r=davidtwco
Auto merge of rust-lang#109507 - Amanieu:panic-oom-payload, r=davidtwco
alloc_error_handler has stabilized
RalfJung commentedon Dec 9, 2023
Given that this issue is closed, why is the unstable book still listing a feature that points here?
https://doc.rust-lang.org/nightly/unstable-book/language-features/alloc-error-handler.html
SimonSapin commentedon Dec 9, 2023
This tracking issue was closed when PR #109507 merged to remove the feature, but that was reverted in PR #110782. Reopening to reflect that.
PR #112331 is open to remove the feature again, and is already marked as closing this.
RalfJung commentedon Jul 22, 2026
That PR got closed in the mean time.
What is preventing this feature from being removed?
StackOverflowExcept1on commentedon Sep 25, 2026
Is there any news after #156882 stabilization?
theemathas commentedon Sep 25, 2026
@StackOverflowExcept1on I'm told that it's blocked on figuring out how to handle unwinding. Don't get your hopes up.