-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Tracking issue for the #[alloc_error_handler] attribute (for no_std + liballoc) #51540
Tracking issue for the #[alloc_error_handler] attribute (for no_std + liballoc) #51540
Comments
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 |
Bikeshedding on |
I forgot to link #51543, which does indeed use |
This removes the need for `no_std` programs to define that lang item themselves: Fixes rust-lang#51540
@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. |
Replying to @glandium's rust-lang/rfcs#2480 (comment) here to not derail the alloc RFC.
Not everyone has to implement their own. An implementation can be packed into a crate and it just takes adding a
Then stabilize
No default OOM handler is good. There's no sensible default for every single combination of Also, not having a default is consistent with both Another reason why I like static registration of global properties is that it's less error prone. Say you want the OOM (or panic) handler to behave differently between development and final release. With #[oom] you can write this: #[cfg(debug_assertions)]
extern crate oom_report; // for development, verbose
#[cfg(debug_assertions)]
extern crate oom_panic; // for release, minimal size This is clearly wrong, you get a compiler error. With the The other reason I like #[oom] / #[panic_implementation] is that you can be sure of the behavior of the OOM / panic if you register the handler in the top crate. extern crate oom_abort; // I'm 100% sure OOM = abort With the hook API you have no guarantee fn main() {
set_alloc_error_hook(|| abort()); // OOM = abort, maybe
dependency::function(); // this is totally free to change the OOM handler
// ..
} Finally, if you need the ability to override the OOM handler at runtime using hooks you can implement that on top of #[oom]. |
@japaric I find this convincing regarding static v.s. dynamic, thanks.
Oh, I was wondering if something like that ever happened. How does one typically deal with unrecoverable situations on MSP430? An infinite loop?
I think we can have a default, with a Sufficiently Advanced Compiler. (Grep for But you’re saying we should not, and force that question on ever |
Right. I think the remaining question is: should there be a default? If not, what should be a "typical" implementation that we’d recommend in docs? Should we add a stable wrapper for The docs for
But besides availability, the two functions do not have equivalent behavior: servo/servo#16899. |
@pftbest and @cr1901 would be more qualified to answer that question. I'm not a MSP430 developer myself. On Cortex-M the abort instruction triggers the HardFault handler. While developing I configure panic and HardFault to log info about the program, or just to trigger a breakpoint if binary size is a problem. In release mode, I usually set panic to abort and make the HardFault handler disable interrupts, shut down the system (e.g. turn off motors), signal the failure (e.g. turn on a red LED) and go into an infinite loop but this is very application specific. Also, in some applications reaching an unrecoverable situation means that something is (very) wrong with your software and that it should not be deployed until it's fixed.
#[global_allocator] is not mandatory for #[no_std] binaries. And the oom lang item is only required when you are using #[global_allocator]. So, no, not all no_std program developers have to deal with the oom handler.
I think there should not be a default.
The #![no_std] application - target space is too broad to recommend anything that will behave the same everywhere. Consider intrinsics::abort:
Yes. As
Those docs should be fixed. iirc process::abort tries to does some clean up (of the Rust runtime?) before aborting the process. intrinsics::abort is an LLVM intrinsic that maps to the abort instruction of the target instruction set so the two are not equivalent. |
oom
lang item)
Infinite loop is how I typically deal w/ it. @pftbest can override me if he knows something better though, as it's been a while since I delved into msp430 internals :). |
#52191 has landed with an attribute for a statically-dispatched function, and no default. |
I'm getting the above in one my projects. I have defined the |
🔔 This is now entering its final comment period, as per the review above. 🔔 |
The final comment period, with a disposition to close, as per the review above, is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. |
…twco Report allocation errors as panics OOM is now reported as a panic but with a custom payload type (`AllocErrorPanicPayload`) which holds the layout that was passed to `handle_alloc_error`. This should be review one commit at a time: - The first commit adds `AllocErrorPanicPayload` and changes allocation errors to always be reported as panics. - The second commit removes `#[alloc_error_handler]` and the `alloc_error_hook` API. ACP: rust-lang/libs-team#192 Closes rust-lang#51540 Closes rust-lang#51245
Seems we no longer need an explicit error handler, remove it. I did not grok the reason (long thread link below) but just removed it and checked that the embedded crates still ran correctly. rust-lang/rust#51540)
d378451 embedded: Remove error handler (Tobin C. Harding) Pull request description: Seems we no longer need an explicit error handler, remove it. I did not grok the reason (long thread link below) but just removed it and checked that the embedded crates still ran correctly. rust-lang/rust#51540 Fix: #1813 ACKs for top commit: Kixunil: ACK d378451 apoelstra: ACK d378451 Tree-SHA512: 76ce3f346e7e4e62595c6a6c415476b0cabcf27ded8e79a3e0b692a98b12ff9e90bec2841d18790bb62a16c553ad60492fc09e1aa4bf550c7070cd29b5ac1702
Report allocation errors as panics OOM is now reported as a panic but with a custom payload type (`AllocErrorPanicPayload`) which holds the layout that was passed to `handle_alloc_error`. This should be review one commit at a time: - The first commit adds `AllocErrorPanicPayload` and changes allocation errors to always be reported as panics. - The second commit removes `#[alloc_error_handler]` and the `alloc_error_hook` API. ACP: rust-lang/libs-team#192 Closes rust-lang#51540 Closes rust-lang#51245
Report allocation errors as panics OOM is now reported as a panic but with a custom payload type (`AllocErrorPanicPayload`) which holds the layout that was passed to `handle_alloc_error`. This should be review one commit at a time: - The first commit adds `AllocErrorPanicPayload` and changes allocation errors to always be reported as panics. - The second commit removes `#[alloc_error_handler]` and the `alloc_error_hook` API. ACP: rust-lang/libs-team#192 Closes rust-lang#51540 Closes rust-lang#51245
Report allocation errors as panics OOM is now reported as a panic but with a custom payload type (`AllocErrorPanicPayload`) which holds the layout that was passed to `handle_alloc_error`. This should be review one commit at a time: - The first commit adds `AllocErrorPanicPayload` and changes allocation errors to always be reported as panics. - The second commit removes `#[alloc_error_handler]` and the `alloc_error_hook` API. ACP: rust-lang/libs-team#192 Closes rust-lang#51540 Closes rust-lang#51245
Seems we no longer need an explicit error handler, remove it. I did not grok the reason (long thread link below) but just removed it and checked that the embedded crates still ran correctly. rust-lang/rust#51540)
Given that this issue is closed, why is the unstable book still listing a feature that points here? |
This attribute is mandatory when using the
alloc
crate without thestd
crate. It is used like this:Implementation PR: #52191
Blocking issues
unsafe fn
which is then unsoundly invoked #134225Original issue:
In a
no_std
program or staticlib, linking to thealloc
crate may cause this error:This is fixed by providing the
oom
lang item, which is is normally provided by thestd
crate (where it calls a dynamically-settable hook #51245, then aborts). This is called byalloc::alloc::handle_alloc_error
(which is called byVec
and others on memory allocation failure).However, defining a lang item is an unstable feature.
Possible solutions include:
#[panic_implementation]
attribute: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.The text was updated successfully, but these errors were encountered: