gtk-rs-core: Not catching panics across FFI boundaries
https://github.com/gtk-rs/cairo/pull/257 added bindings for “user data” owned by cairo objects. Each user data entry has a destructor function pointer that cairo calls when the object is destroyed. This helps solve life time issues, since with reference counting it can be hard to predict when an object will be destroyed exactly.
The bindings are generic and accept user data of any type. They forward destructor function pointer calls to Drop, which potentially panic and unwind. However, until https://github.com/rust-lang/rust/issues/58794 is resolved, unwinding into C is undefined behavior.
A possible fix is using std::panic::catch_unwind in the destructor function. However even if we stash the panic payload somewhere at that point, there is no good place in the code to call resume_unwind. So the best we can do might be to abort the process.
About this issue
- Original URL
- State: open
- Created 5 years ago
- Comments: 18 (15 by maintainers)
Currently any unwinding across
extern "C"functions is UB, even if all those functions happens to be implemented in Rust. That’s part of what that WG is working on solving.For example this adds support for an
extern "C-unwind"ABI that explicitly allows unwinding (and AFAIU causes unwinding throughextern "C"to abort as it should).There’s a whole WG about that: https://rust-lang.github.io/rfcs/2797-project-ffi-unwind.html / https://github.com/rust-lang/project-ffi-unwind . It’s not finished yet.