Stream: project-ffi-unwind

Topic: Forced unwinding, POFs, and "cancelable" annotation


view this post on Zulip BatmanAoD (Kyle Strand) (Aug 02 2020 at 22:15):

I know Niko wanted the group to take a break from doing spec-work for a bit, but I do want to start thinking about what the requirements are for making longjmp &co well defined.

We already have some thoughts about what a specification will eventually look like:

The only hard requirements I'm aware of are:

view this post on Zulip Amanieu (Aug 03 2020 at 19:27):

I don't think supporting pthread_cancel is a hard requirement. We could just say that pthread_cancel is UB if canceling a thread that has a Rust frame on the stack.

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 03 2020 at 20:01):

I thought that was the primary reason we have UB in libc calls?

view this post on Zulip Amanieu (Aug 03 2020 at 20:37):

We can just punt the safety responsibility to the caller of pthread_cancel (which is FFI an therefore unsafe).

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 03 2020 at 20:39):

But if it's UB to have Rust on the stack at all, there's no way to actually uphold that responsibility...right?

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 05 2020 at 16:23):

@RalfJ Is calling libc functions that may pthread_cancel one of the soundness issues you are concerned about? I thought it was the primary one.

view this post on Zulip RalfJ (Aug 05 2020 at 16:46):

pthread_cancel is definitely on the "horribly unsound" list of things

view this post on Zulip RalfJ (Aug 05 2020 at 16:47):

I dont think I have a primary soundness concern about unwinding, I just dont know enough about it. I dont have a big-picture view. I just know some bits and pieces.

view this post on Zulip bjorn3 (Aug 05 2020 at 18:00):

Can we make the personality function abort on forced unwinds? That would solve the whole unsoundness on systems using DWARF unwinding. It should also be possible to detect POF's from the personality function if you only want to abort for non-POF's.

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 05 2020 at 18:54):

See my first post: we don't want to specify different behavior for the same language feature depending on what implementation the platform uses. longjmp should either work if the code is correct, or not.

view this post on Zulip bjorn3 (Aug 05 2020 at 19:04):

longjmp doesn't use forced unwindings on platforms using DWARF unwinding, only on Windows with SEH, right?

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 05 2020 at 19:05):

Correct. Sorry, I didn't just mean longjmp; I also mean pthread_exit.

view this post on Zulip bjorn3 (Aug 05 2020 at 19:16):

Windows doesn't have pthread_exit, right?

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 05 2020 at 19:19):

I suspect that it exists as part of MinGW, but no, native MSVC-based runtimes shouldn't.

view this post on Zulip Peter Rabbit (Aug 07 2020 at 00:14):

bjorn3 said:

Windows doesn't have pthread_exit, right?

It has ExitThread which as far as I can tell does roughly the same thing that pthread_exit does.

view this post on Zulip bjorn3 (Aug 07 2020 at 08:17):

Does Windows have a way to detect this kind of forced unwinding and abort when it happens, but not abort on longjmp?

view this post on Zulip Peter Rabbit (Aug 07 2020 at 14:43):

It's not really unwinding. The thread just terminates, the stack is deallocated, any pending IO is cancelled, and anything with destructors is totally leaked.

view this post on Zulip BatmanAoD (Kyle Strand) (Aug 07 2020 at 21:01):

My primary point about the cross-platform differences is that from the perspective of Rust's (currently informal) specification, the language features in question (thread termination and longjmp) should not be specified differently depending on the target platform's implementation of the feature.

In other words, the user should not need to know whether such features are implemented with forced unwinding or simple stack deallocation.


Last updated: Jan 26 2022 at 07:32 UTC