Stream: project-ffi-unwind

Topic: pyo3 (python / c) ffi unwind


David Hewitt (Apr 08 2020 at 21:20, on Zulip):

Hello, I've been recently looking into panic behavior in pyo3, with a draft PR (https://github.com/PyO3/pyo3/pull/797) using catch_unwind to guard against current UB (as I understand it) of unwinding through CPython stack frames. (For Rust functions called by the Python interpreter.)

If I'm reading the ffi-unwind group materials correctly, it sounds like the "C unwind" ABI would also make panics well-defined without needing to introduce catch_unwind. Is that correct?

If you're interested in any details of pyo3 that would be relevant to this group's work, I'd be happy to deliver them. Thanks.

Amanieu (Apr 08 2020 at 21:23, on Zulip):

Note that the FFI code you are unwinding into also needs to support unwinding by performing the proper cleanups on unwind. So this only really works for C++ code, not C.

BatmanAoD (Kyle Strand) (Apr 08 2020 at 21:35, on Zulip):

...unless your C code doesn't need any sort of "cleanup"; I think it's correct to think of it as being semantically identical to longjmp over the unwound frames.

Amanieu (Apr 08 2020 at 21:36, on Zulip):

Your C code does need to be compiled with -fexceptions though.

BatmanAoD (Kyle Strand) (Apr 08 2020 at 21:36, on Zulip):

Right.

BatmanAoD (Kyle Strand) (Apr 08 2020 at 21:37, on Zulip):

But in the pyo3 case, the cpython frames are the Python interpreter itself, right? It seems unlikely that any Python user would want that.

BatmanAoD (Kyle Strand) (Apr 08 2020 at 21:37, on Zulip):

...and of course it's unlikely that the Python interpreter's stack frames are "clean-up free".

BatmanAoD (Kyle Strand) (Apr 08 2020 at 21:38, on Zulip):

So catch_unwind seems very preferable.

David Hewitt (Apr 08 2020 at 21:44, on Zulip):

Great, that makes sense, thanks. The model we're heading toward is to use catch_unwind convert a Rust panic into a Python exception at the language boundary, and let the interpreter bubble it up through the "Python" stack frames.

David Hewitt (Apr 08 2020 at 21:46, on Zulip):

It then seems reasonable that if that Python exception gets returned to Rust code in some higher stack frame we should then restart Rust's unwinding with resume_unwind.

David Hewitt (Apr 08 2020 at 21:48, on Zulip):

If we did this catch / resume unwind dance, would "C unwind" simply offer no benefit here then? Or would it actually be actively harmful if the Python interpreter is not compiled with -fexceptions

Amanieu (Apr 08 2020 at 21:50, on Zulip):

"C unwind" is probably not useful for your case. You want to turn a Rust panic into a Python exception, but "C unwind" turns a Rust panic into a C++ exception.

David Hewitt (Apr 08 2020 at 21:55, on Zulip):

Ok great. Thanks! :thumbs_up:

Last update: Jun 05 2020 at 23:15UTC