Double-panic behavior on C++->Rust unwinding

[gnzlbg]

This code:

fn main() {
    foo();
}

fn foo() {
    let _x = Foo;
    unsafe { bar() }
}

// note: the `unsafe` allows replacing this with 
// an `extern "C unwind"` below:
unsafe fn bar() { panic!("bar"); }

struct Foo;
impl Drop for Foo {
    fn drop(&mut self) {
        panic!("Foo");
    }
}

is guaranteed to panic twice, once printing "bar" and once again printing "Foo", and then, the program aborts due to the double panic printing "thread panicked while panicking. aborting".

I wonder what would happen if we replace bar above with an extern "C unwind" { fn bar(); } function implemented in C++ as extern "C" void bar() { throw "bar"; } or similar (e.g. throwing a std::string("bar"), std::runtime_exception("bar"), etc.).

• How would we detect a double panic?
• What error message would be printed?

[BatmanAoD]

Initially, I think it's reasonable to consider this undefined behavior.

We will need to look at how the double panic is currently detected and determine whether this will already detect panic-while-unwinding caused by foreign exceptions. If it can, perhaps we should just change the error message to "thread panicked while unwinding. aborting". (I don't think it would be terribly valuable to make the mechanism detect why the unwind is occurring and explain this to the user.)

[gnzlbg]

I think we probably want to extend the UB initially to the opposite case as well, that is, when a Rust "C unwind" function panics and in C++ a noexcept(false) destructor throws.

This means that a safe extern "C unwind" Rust function can cause UB when called from C++, but that's ok I think.

[BatmanAoD]

I think we probably want to extend the UB initially to the opposite case as well, that is, when a Rust "C unwind" function panics and in C++ a noexcept(false) destructor throws.

This is what I was referring to on Zulip about "defining the behavior of native (non-Rust) code when attempting to throw while a Rust panic is already in-flight."

I don't understand how Rust could specify this behavior for C++.

[gnzlbg]

@BatmanAoD ah, I completely misunderstood you then, since I left very similar comments in the PR. So yes, I agree this is wrong:

I think we probably want to extend the UB initially to the opposite case as well, that is, when a Rust "C unwind" function panics and in C++ a noexcept(false) destructor throws.

We can't specify this. What we can do is document that, if this happens, the C++ standard doesn't make any guarantees about this behavior, and document what guarantees each of the target implementations makes. For example, Itanium-C++ says that if a foreign exception, e.g., thrown by Rust, causes C++ to throw while unwinding, the behavior is undefined.

[gnzlbg]

For future reference (https://itanium-cxx-abi.github.io/cxx-abi/abi-eh.html#base-personality):

The behavior is undefined in the following cases:

[...]
A __foreign_exception is active at the same time as another exception (either there is a nested exception while catching the foreign exception, or the foreign exception was itself nested).

EDIT: this is the behavior that C++ on targets with the Itanium ABI has, when a foreign exception, such as the one caused from unwinding from Rust into C++, triggers a double-drop in C++.

[BatmanAoD]

Okay, thanks for the clarifications.

Would you mind submitting a PR adding some verbiage to the roadmap to the effect that panic-while-unwinding-foreign-exceptions is undefined?

[gnzlbg]

Would you mind submitting a PR adding some verbiage to the roadmap to the effect that panic-while-unwinding-foreign-exceptions is undefined?

So I made the behavior of this implementation defined in #9 , which on x86_64-apple-darwin and x86_64-unknown-linux-gnu (and probably all other Itanium targets, like FreeBSD) can be defined to abort, since on such targets, panic! can just check if we are already unwinding, and if so, whether the current on flight exception originated in Rust or in some other programming language, and act accordingly and abort. For the case in which both panics originate in Rust the error message will probably be nicer than when one of the panics is foreign, because we can print the error messages of both panics. When the panic is foreign, we should be able to at least print a stack trace.