Techcable
commented
6 years ago I often wish that this was the case, given that most managed languages have this feature and preventing segfaults is a major goal of rust.
Unfortunately, this could break panic safety and introduce undefined behavior.
It is very common for unsafe code to assume that certain functions can never panic based on both documented or undocumented guarantees. For example ptr::copy_nonovoerlapping ptr.offset and ptr::write are often assumed to never panic.
vec.reserve(1);
unsafe {
let i = vec.len();
let p = vec.as_mut_ptr();
// Right now `vec[i]` is uninitialized and should never be observed by user code
vec.set_len(vec.len() + 1);
/*
* Keeping `vec[i]` uninitlaized is safe as long as untrusted user code
* can never read the uninitialized memory because it's never called.
* Since we never directly invoke untrusted code,
* our only risk is from panicking causing user destructors to run.
* Because `ptr::copy_nonoverlapping` and `ptr.offset` never panic we
* should be safe and users will never see our uninitialized memory.
*/
ptr::copy_nonoverlapping(existingPointer, p.offset(i), 1));
}If stack overflows could trigger a panic then both ptr::copy_nonoverlapping and ptr.offset are turned into potentially panicking functions. The stack could unwind and user code could observe the uninitialized memory when running their destructors.
This could trigger a large amount of potential unsafety across the stdlib and entire ecosystem. Furthermore, it makes it nigh on impossible to write correct unsafe code in the future because crucial functions like ptr::copy_nonoverlapping and ptr::write can now panic.
First of all, we could unwind the stack without calling the destructors, which should avoid most cases of untrusted code seeing unsafe states. The downside of this approach is that it leaks memory and may be unsound.
The other alternative is a system to mark functions as #[nopanic].
Then we could statically know which functions are 'allowed' to panic without impacting memory safety. If a #[nopanic] function is on the stack during stack overflow, it'd be forbidden to panic and we would trigger an abort to avoid undefined behavior. Otherwise, the function is allowed to panic and the runtime would prefer that when dealing with a stack overflow.
This would force unsafe code to statically mark all their assumptions about which functions can and can not panic in order to retain memory safety. However, this would still be a major barrier to adoption and would probably require an RFC before it could be relied on.
gilescope
jonas-schievink
sfackler
retep998
da-x
jyn514
philipc
sjep
matklad
hamirmahal
As a coder Given I have a fn main() { main() } Then I expect the following output:
Obviously this is an example of how Java handles stack overflows, but you get the idea.
There didn't seem to be a tracking issue for this, so here is one. (Some discussion here: https://users.rust-lang.org/t/how-to-diagnose-a-stack-overflow-issues-cause/17320/9 )
I've had a little look and I naively think we need to do something like this in sys_common/util.rs
Quite possibly one can ditch the first panic checks. I'm sure there's lots of concerns here, e.g. have we got enough stack headroom to report without going pop.