panic in a no-unwind function leads to not dropping local variables

[RalfJung]

Raised by @CAD97:

I actually find the current behavior of #![feature(c_unwind)] unwinding in extern "C" somewhat strange. Specifically, any unwinding edges within the extern "C" fn get sent to core::panicking::panic_cannot_unwind, meaning that the unwind happens up to the extern "C" fn, but any locals in said function don't get dropped. I would personally not expect wrapping the body of an extern "C" function in an inner extern "Rust" function to change behavior, but it does.

Reproducing example:

#![feature(c_unwind)]

struct Noise;
impl Drop for Noise {
    fn drop(&mut self) {
        eprintln!("Noisy Drop");
    }
}

extern "C" fn test() {
    let _val = Noise;
    panic!("heyho");
}

fn main() {
    test();
}

I would expect "Noisy Drop" to be printed, but it is not.

IMO it'd make most sense to guarantee that with panic=unwind, this destructor is still called. @nbdd0121 however said they don't want to guarantee this.

What is the motivation for leaving this unspecified? The current behavior is quite surprising. If I understand @CAD97 correctly, we currently could make "Noisy Drop" be executed by tweaking the MIR we generate.

Tracking:

• Tracking Issue for "C-unwind ABI", RFC 2945 #74990

[RalfJung]

Nominating for t-lang discussion to get their vibe on this question.

[nbdd0121]

There's prior discussion here: https://rust-lang.zulipchat.com/#narrow/stream/210922-project-ffi-unwind/topic/Behaviour.20of.20destructors.20wrt.20terminate.2Fabort

[RalfJung]

Wow that was years ago. What's the take-away from that discussion?

[nbdd0121]

As pointed out in the discussion, changing how we insert abort to functions is sufficient to change the observed behaviour of the implementation, but the key is to decide what's the allowed behaviour of any implementation.

Options:

• To not call any destructors if panic happens in no-unwind context.
  • Is quite desirable and can be helpful for debugging
  • This is currently the behaviour for MSVC SEH in cleanup context.
  • We probably can't implement this behaviour for all platforms.
• To call all destructors before the unwind.
  • Additional code needs to be injected to guarantee this (especially for MSVC SEH cleanup case)
  • Questionable value about running all destructors if abort is to happen.
• Leave it unspecified whether destructors will be called at all, or how many call frames are to be unwound before aborting.
  • Maximum flexibility for implementation
  • Consistent with C++'s std::terminate specification.
  • Can avoid adding landing pads and destructor code if we know for certain abort is about to happen.

Some additional complexity involves a foreign exception. For example, if we have a mixture of stack frames with C++ and Rust then any specification may result in surprises. E.g. when a nounwind frame is introduced by a C++ noexcept function, it's up to C++ personality function to decide whether a Rust panic may trigger C++ std::terminate in phase 1 unwinding before any Rust destructor is called, or trigger in phase 2 after Rust destructor is called and terminate when it reaches C++. If we have a C++ -> Rust -> C++ -> Rust call stack if will mean that we might have some Rust frames have destructors called but not other Rust frames.

cc @rust-lang/wg-ffi-unwind

[RalfJung]

To not call any destructors if panic happens in no-unwind context.

Judging from prior discussion, "no-unwind context" is a very specific technical term here and not something visible in Rust? Or what exactly do you mean?

Is quite desirable and can be helpful for debugging

Why? If by this you mean the current behavior, I find it undesirable and confusing and thus hindering debugging.

Or do you mean that the panic will somehow predict whether it will during its unwinding hit a no-unwind stack frame and then change behavior early on? That's spooky-action-at-a-distance, so I also don't think that's desirable.

Maximum flexibility for implementation

That's a pretty poor argument IMO, our job is to provide consistent and predictable semantics to our users whenever that is possible with reasonable performance.

Some additional complexity involves a foreign exception.

For this issue I only care about Rust panics.

[nbdd0121]

Let me explain in greater detail, this'll be long..

For unwinding, there are a few type of cases for nounwind/noexcept/whatever:

1. A stack frame contains no unwind metadata / reaches end of frame
2. Personality function determines the callsite is nounwind and unwinding should terminate
3. There's a try/catch and the exception handler calls terminate.

Unwinders can either do single phase unwinding, or do two phase unwinding. For the latter, it do a unwind first without calling any destructors to find the frame that will catch the exception, and then starts an unwind with cleanups. If a catching frame cannot be found, the unwinding process fails at phase 1 (Let's ignore forced unwind for now). The Itanium C++ ABI unwinder has two phases.

So if you have a C code (compiled without unwind tables) that calls into Rust C-unwind function and panics, then it's case (1), and phase 1 will fail. No destructor will be executed.

A C++ noexcept function is of case (2) in GCC. With GCC's personality function implementation, the phase 1 will consider a noexcept function as a catching frame, and complete (stop at this frame) without failing. When unwind happens into the noexcept frame, no cleanup is performed and a termination happens immediately (similar to Rust's behaviour today).

A C++ noexcept function is of case (3) in Clang because it doesn't yet support encoding the information to be exposed to personality function. noexcept is codegened as try {...} catch(...) { terminate() } (roughly). Since it's a catch, phase 1 will stop at the frame. Upon phase 2 reaching this frame, it will execute terminate() without calling any destructors in the final frame (since it's a try/catch and thus terminate is executed with the variables still in-scope, so rightfully the destructor of the last frame is skipped). This is also similar to Rust's behaviour today.

There's a subtle difference between (2) and (3) w.r.t to optimisation. Say we have this code:

#include <cstdio>

struct D {
    ~D() {
        fprintf(stderr, "Drop!\n");
    }
};

static void foo() {
    D d;
    throw "";
}

static void bar() noexcept {
    D d;
    foo();
}

int main() {
    bar();
}

in both GCC and Clang, you will get one Drop! print only. If you turn on GCC's optimisation though, you will get no Drop! prints. You still get one Drop! print with Clang + opt. In no cases you get two prints. They're all acceptable behaviour because C++ spec says in this case it is unspecified whether the destructors are called.

The Rust behaviour today is very similar to clang's behaviour in the example.

---

Now to answer your questions

Or do you mean that the panic will somehow predict whether it will during its unwinding hit a no-unwind stack frame and then change behavior early on? That's spooky-action-at-a-distance, so I also don't think that's desirable.

Yes, I mean this. Since unwind is of two phases, the phase 1 can determine if unwind is possible and can skip phase 2 entirely. It's already the case that Rust panic will cause nounwind at all if it escapes into functions with no unwind tables, or, with MSVC SEH, into cleanup code.

It's helpful for debugging because all the stack frames are intact so you can inspect all frames upon abort. Currently when we unwind, hit an extern "C" frame, and print a panic-cannot-unwind message. If RUST_BACKTRACE is not enabled, then the first panic prints no stack trace and you already lost the information when abort happens. What could been done is to use phase 1 to figure out that unwind will cause terminate, and then print stack trace, along with an indication of which frame prevents the unwinding from happening.

That's a pretty poor argument IMO, our job is to provide consistent and predictable semantics to our users whenever that is possible with reasonable performance.

Given FFI is very important regard to extern "C" and all unwindable ABIs, I think it's also important to consider consistency with other languages. At detailed above, the implementation today is very consistent with C++ implementation's behaviour.

We certainly can define the behaviour to be "all destructors" being executed. It'll simply be requiring adding try/catch around all extern "C" functions. However, I am not sure it'll be desirable. When GCC backend is getting better or if LLVM adds support for encoding an "terminate" action, this will prevent us from moving over from case (3) to case (2) which can reduce code size quite significantly.

If leaving this unspecified allows better optimisation w.r.t. landing pad sizes, then IMO we should allow such optimisation given that a panic escaping to unwindable FFI interface is very rare and almost always a bug (given abort is imminent). If one wants all destructor to be called, they can very easily implement that behaviour with catch_unwind.

Some additional complexity involves a foreign exception.

This will happen with Rust panic in presence with foreign frames, as well as foreign exception with Rust frames. I think it'll less consistent if our specification of Rust panic behaviour depends on whether a foreign frame is present or not.

[RalfJung]

I'll reply in full later, for now I have a clarification question:

The Itanium C++ ABI unwinder has two phases.

Itanium is dead, why should we care? 2-phase unwinding sounds like a lot of unnecessary complexity to me.^^ But I guess they had their reasons.

[chorman0773]

The Itanium C++ ABI is the abi used by gcc and clang on most non-windows targets.
The ABI was standardized for IA-64, hense the name, but the spec is used on many platforms.

Rust already uses Itanium EH for panics on the same set of targets.