Description
This is the tracking issue for the behavior of unwinding through FFI functions.
There are two choices here: we can abort if unwinding occurs through an extern "C"
boundary. We abort on beta 1.34 and nightly 1.35, but will permit unwinding in stable 1.33.
We previously attempted this change in 1.24 and reverted in 1.24.1. We attempted to do so again in 1.33, but reverted once again pending lang team discussion on the topic.
There has been discussion on this topic in #52652, #58760, and #55982.
The stable behavior of permitting unwinding is UB, and can be triggered in safe code (#52652 (comment)). Notably, mozjpeg
depends on this behavior and seems to have no good stable alternatives; there's been some discussion on internals.
There is an RFC discussing this: rust-lang/rfcs#2699.
Activity
jethrogb commentedon Feb 28, 2019
It would be helpful for the discussion if someone knowledgeable could write a summary covering the following:
When I say major platforms, I mean GNU libunwind, Windows SEH, possibly others.
Is it possible to have different default behavior depending on which unwinder you're using? Say, unwind normally on major platforms, abort on others?
comex commentedon Feb 28, 2019
In another thread, @alexcrichton wrote:
As for the current implementation, my understanding is: on Unix it works; on Windows it mostly works, with some issues that could be solved. See my comment in that thread for more details.
On Unix, longjmp just resets the stack pointer and ignores unwinding.
On Windows, longjmp triggers SEH unwinding and so will run Rust destructors, AFAIK. *
* (I said in other threads that it didn't, because I misread the description of this PR and thought that it changed things so destructors wouldn't run when unwinding via longjmp; in reality, it only did that to the abort-on-unwind handler itself.)
nagisa commentedon Feb 28, 2019
As far as the last part of that is concerned, that is an implementation-specific and unspecified behaviour.
Centril commentedon Mar 10, 2019
The current behavior on stable amounts to a soundness hole. For example, based on #52652 (comment), we can write (playground):
The behavior of this program is undefined on stable because we attach the
nounwind
LLVM attribute tobad
.Soundness is non-negotiable and as such we landed #55982 to close this soundness hole. However, since there was no explicit confirmation of this step by the language team the change was reverted on 1.33 pending confirmation. The change is still seen in beta and nightly compilers.
Based on notes by @alexcrichton in #52652 (comment), #55982 (comment), #55982 (comment), and #55982 (comment), I propose that we go ahead with and confirm the change in #55982.
@rfcbot merge
rfcbot commentedon Mar 10, 2019
Team member @Centril has proposed to merge this. The next step is review by the rest of the tagged team members:
Concerns:
blocked-on-rfc-2699resolved by Default behavior of unwinding in FFI functions #58794 (comment)Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!
See this document for info about what commands tagged team members can give me.
167 remaining items