Panic in 'safe' extern "C" causes SIGILL

[ralfbiedert]

Investigating a SIGILL in a safe library of ours I could reduce the crash to the following code:

#![deny(unsafe_code)]

extern "C" fn crash() {
    panic!("End of the world");
}

fn main() {
    // This works ...
    std::panic::catch_unwind(|| panic!("Oh no"));

    // This will cause a STATUS_ILLEGAL_INSTRUCTION and crash the app.
    std::panic::catch_unwind(|| crash());

    println!("Still running ...");
}

When running the above with cargo run:

thread 'main' panicked at 'Oh no', src\main.rs:9:33
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.
thread 'main' panicked at 'End of the world', src\main.rs:4:5
error: process didn't exit successfully: `target\debug\app.exe` (exit code: 0xc000001d, STATUS_ILLEGAL_INSTRUCTION)

Link to playground.

Although one can argue that decorating crash with extern "C" is ugly, observe that there is no unsafe involved in this code. Panicking past the "safe" extern "C" boundary is enough.

I can provoke this with

• rustc 1.38.0-nightly (83e4eed16 2019-07-14)
• rustc 1.39.0-nightly (bdfd698f3 2019-08-16)

When compiling with rustc 1.37.0 (eae3437df 2019-08-13) it seems to work.

[sfackler]

You cannot generally unwind through a C ABI: #58794

[ralfbiedert]

You cannot generally unwind through a C ABI: #58794

But isn't "safe" Rust meant to be free of undefined behavior?

Edit - I'm implying here that the ud2 I'm receiving in gdb signals UB. Nevermind, I just read the other thread, seems like all the arguments have been made there already. Feel free to close this issue as duplicate.

[jonas-schievink]

Closing in favor of #58794