pthread_exit no longer works in panic=abort

[programmerjake]

I tried this code:
https://rust.godbolt.org/z/M5Pz1rjnd

#![feature(c_unwind)]
#![no_main]
use std::ffi::{c_void, c_int, c_char};
use std::ptr::null_mut;

extern "C-unwind" {
    fn pthread_exit(v: *mut c_void) -> !;
}

#[no_mangle]
pub unsafe extern "C-unwind" fn main(_argc: c_int, _argv: *mut *mut c_char) {
    unsafe {pthread_exit(null_mut())}
}

I expected to see this happen: exits with exit code 0 as documented for pthread_exit

Instead, this happened: aborts with double panic

Meta

rustc --version --verbose:

rustc 1.65.0-nightly (8c6ce6b91 2022-09-02)
binary: rustc
commit-hash: 8c6ce6b91b172f77c795a74bfeaf74b865146b3f
commit-date: 2022-09-02
host: x86_64-unknown-linux-gnu
release: 1.65.0-nightly
LLVM version: 15.0.0

sorry, i can't figure out how to get a backtrace from godbolt.org, it doesn't seem to allow setting environment variables.

This bug serms to be caused by #96959

@rust-lang/wg-ffi-unwind

[programmerjake]

i expect this to work because pthread_exit is supposed to do a force-unwind, which RFC 2945 (specifically referenced by #96959) states:

panic=abort will have no impact on the behavior of forced unwinding.

[nbdd0121]

The RFC defines force unwind as undefined behaviour when it cross non-POF, which your example does.

[programmerjake]

The RFC defines force unwind as undefined behaviour when it cross non-POF, which your example does.

show me the live variables with a Drop impl or the catch_unwind-style call...those are the two conditions in the RFC for a frame to not be a plain-old-frame. The code I wrote has neither of those, so should be a plain-old-frame.

[nbdd0121]

The RFC says:

A "POF", or "Plain Old Frame", is defined as a frame that can be trivially deallocated: returning from or unwinding a POF cannot cause any observable effects.

Unwinding through "C-unwind" in -Cpanic=abort is defined to cause an abort according to my reading of the RFC (not saying that it's correct, but it's my reading of the RFC), so the frame is not trivially deallocated and thus not POF.

[bjorn3]

As I understand it a POF is any frame without pending destructors or catch_unwind calls. Neither is the case in this example.

[BatmanAoD]

@nbdd0121 That would make every use of "C-unwind" a non-POF. I'm pretty sure that wasn't the intent... but you're right that the verbiage implies the opposite.

[BatmanAoD]

This paragraph below makes explicit that "C-unwind" frames can be POFs:

This RFC specifies that, regardless of the platform or the ABI string ("C" or "C-unwind"), any platform features that may rely on forced unwinding will always be considered undefined behavior if they cross non-POFs. Crossing only POFs is necessary but not sufficient, however, to make forced unwinding safe, and for now we do not specify any safe form of forced unwinding; we will specify this in a future RFC.

[programmerjake]

The RFC says:

A "POF", or "Plain Old Frame", is defined as a frame that can be trivially deallocated: returning from or unwinding a POF cannot cause any observable effects.

Unwinding through "C-unwind" in -Cpanic=abort is defined to cause an abort according to my reading of the RFC (not saying that it's correct, but it's my reading of the RFC), so the frame is not trivially deallocated and thus not POF.

it's defined to cause an abort only for non-forced unwinds, forced unwinds are specifically specified to work despite panic=abort:
https://github.com/rust-lang/rfcs/blob/master/text/2945-c-unwind-abi.md#interaction-with-panicabort

If a non-forced foreign unwind would enter a Rust frame via an extern "C-unwind" ABI boundary, but the Rust code is compiled with panic=abort, the
unwind will be caught and the process aborted.
...
panic=abort will have no impact on the behavior of forced unwinding.

[BatmanAoD]

I think @nbdd0121 is right that the definition of POF is somewhat confusing here. But certainly this should be considered a POF. "POF-ness" should never depend on the panic mode or the ABI string. These are worth calling out in the Reference, or possibly in a future RFC, presumably one where we define how longjmp works. I've posted about this before on the Inside Rust blog, complete with an alternate definition of POFs:

These are frames that can be trivially deallocated, i.e., they do no "cleanup" (such as running Drop destructors) before returning.

[nbdd0121]

I discussed this yesterday with @bjorn3 about this. The problem is that, for a nounwind function that calls a "C-unwind"` function, with otherwise no destructors, will have to:

• Abort for an unforced unwind (Rust panic or foreign exception);
• Do nothing for a forced unwind.

In order to satisfy the first requirement, we have to insert landing pads to "C-unwind" call-sites to abort the program in case it unwinds. It should be noted that LLVM don't have any mechanisms for generating custom LSDA data, and all exception handling info emitted by LLVM follows the GCC except table format. So we don't have a way to annotate a call-site to let the personality function know that these landing pads should be ignored for forced unwind.

The most reasonable way would be to tweak the personality function so that all landing pads are ignored for a forced unwind. This means that the destructors will not be ran at all for a forced unwind, but that should be okay as we define unwinding across non-POF frames as undefined behaviour. This method however is not very portable because there are platforms that we don't use our own personality function, such as EMCC and MSVC.

For MSVC we have #48572 which should avoid the aborting landing pad (catchpad) from being called. I am not sure about EMCC though (is forced unwind a thing for emscripten?)

---

Overall, I think allowing forced unwind through a nounwind function is quite problematic on platforms that does not require unwind table to always exist. With -C force-unwind-tables=no and -C force-frame-pointers=no, how would the unwind runtime be able to correctly unwind through a nounwind function?

[BatmanAoD]

The most reasonable way would be to tweak the personality function so that all landing pads are ignored for a forced unwind. This means that the destructors will not be ran at all for a forced unwind, but that should be okay as we define unwinding across non-POF frames as undefined behaviour.

Yes, and that's exactly why we defined it that way! 😁

This method however is not very portable because there are platforms that we don't use our own personality function, such as EMCC and MSVC.

...even after #92845? Dang.

With -C force-unwind-tables=no and -C force-frame-pointers=no, how would the unwind runtime be able to correctly unwind through a nounwind function?

Maybe I'm not understanding the question, but forced unwind is, effectively, exactly like longjmp. As long as the stack frames are deallocated, the unwinding is "correct".

@Amanieu @nbdd0121 @bjorn3

[bjorn3]

Maybe I'm not understanding the question, but forced unwind is, effectively, exactly like longjmp. As long as the stack frames are deallocated, the unwinding is "correct".

With longjmp you know the exact place to jump to because it is passed in as argument. With forced unwind, you unwind the stack to find the right location and depending in the platform and language destructors will still run. As for windows where longjmp is implemented using forced unwind, I believe unwind tables are mandatory.