Stream: project-ffi-unwind

Topic: pyo3 (python / c) ffi unwind


view this post on Zulip David Hewitt (Apr 08 2020 at 21:20):

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 helpful / relevant to this group's work, I'd be happy to offer them. Thanks.

view this post on Zulip Amanieu (Apr 08 2020 at 21:23):

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.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 08 2020 at 21:35):

...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.

view this post on Zulip Amanieu (Apr 08 2020 at 21:36):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 08 2020 at 21:36):

Right.

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 08 2020 at 21:37):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 08 2020 at 21:37):

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

view this post on Zulip BatmanAoD (Kyle Strand) (Apr 08 2020 at 21:38):

So catch_unwind seems very preferable.

view this post on Zulip David Hewitt (Apr 08 2020 at 21:44):

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.

view this post on Zulip David Hewitt (Apr 08 2020 at 21:46):

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.

view this post on Zulip David Hewitt (Apr 08 2020 at 21:48):

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

view this post on Zulip Amanieu (Apr 08 2020 at 21:50):

"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.

view this post on Zulip David Hewitt (Apr 08 2020 at 21:55):

Ok great. Thanks! :thumbs_up:


Last updated: Jan 26 2022 at 07:20 UTC