Attempts to catch_unwind (on Linux) result in SIGABRT #2102
Comments
|
Thanks for reporting this. TLDR; my guess is that there's a foreign (C++?) exception which is interacting with My current understanding of unwinding and panics (and foreign exceptions) is derived from RFC 2945. Basically, we're stuck between a rock and a hard place, because the current state of unwinding in Rust is the following:
I would be tempted to guess that pants has code throwing a C++ exception (or possibly reaches functions like Unfortunately, I don't know if there's anything which PyO3 can do right now to resolve. I think possible action points for the future:
That said, I'm happy to explore suggestions for anything we could do in the meanwhile. We could, for example, add a |
|
cc @acfoltzer @BatmanAoD - in case you're interested in the interaction of |
This could be possible, yea. One strange datapoint against this being a (C++) exception though is that when we apply this patch: pantsbuild/pants#14253 ... to attempt to capture more details, the error no longer reproduces. The user used the branch for a few days without experiencing the issue again. I'm going to end up landing the debug output as a "fix" for the issue/heisenbug, and will report back if shifting the signature really does end up avoiding the issue on a longer time frame. |
…`. (#14253) Adds debug output to attempt to catch what we thought was a panic being converted into an abort, but which might just be an all-natural abort from another source. See PyO3/pyo3#2102 for some discussion of the relevant problem. Beyond just being debug output, this patch actually seems to avoid the issue for the user who was experiencing it. [ci skip-build-wheels]
…`. (pantsbuild#14253) Adds debug output to attempt to catch what we thought was a panic being converted into an abort, but which might just be an all-natural abort from another source. See PyO3/pyo3#2102 for some discussion of the relevant problem. Beyond just being debug output, this patch actually seems to avoid the issue for the user who was experiencing it. [ci skip-build-wheels]
…`. (cherrypick of #14253) (#14692) Adds debug output to attempt to catch what we thought was a panic being converted into an abort, but which might just be an all-natural abort from another source. See PyO3/pyo3#2102 for some discussion of the relevant problem. Beyond just being debug output, this patch actually seems to avoid the issue for the user who was experiencing it. [ci skip-build-wheels]
|
...ah. Indeed it was: rust-lang/rust#70212 From the description, it does sound to me like removing the |
|
From the backtrace I can tell that this is due to |
|
@BatmanAoD @Amanieu thanks for the insights 👍 I keep flip-flopping back and forth on what the right thing to do here is. It's very typical that when a panic occurs in user code in PyO3 that there's a whole sandwich of different frames originating in Rust and also the (C) Python interpreter. Probably in layers e.g. Rust -> C -> C -> Rust -> Rust -> Rust -> C -> C ... I assume that the C code will not use frame destructors for RAII, so by allowing a panic to traverse the interpreter's frames we're almost certainly leaking resources, and potentially corrupting the interpreter state. I think that leaves two workable alternatives for the long-term:
The second option is the current state of PyO3. It frustrates me a little bit for two reasons:
A quick snippet of the output of Overall the |
|
The current behavior is the correct one: you must catch any panics that occurs in Rust code to prevent them from unwinding into the C frames of the Python interpreter. Using Note that Note that the specific issue in this thread is unrelated to this: calling |
|
Actually, I believe that with I think that seems like the right behavior for a library interacting with Python (or any other JVM written in C without explicit unwinding support); is there a design intent to actually support throwing and catching |
|
Thanks both, having your expert input here is really helpful. Adopting the Exploring |
Bug Description
Some code within a
pyfunctionis panicing, but rather than this resulting in aPyExceptionvia #797, it leads to a SIGABRT.A related issue was previously reported here: pantsbuild/pants#13526 (comment) ... the fix for #1990 probably removed a panic, but other panics still seem to trigger the SIGABRT.
Steps to Reproduce
Unfortunately, the triggering panic is non-deterministic, and seemingly only occurs on Linux. Directly triggering a panic within the relevant
pyfunction, properly results in apyo3_runtime.PanicException. I'll try to report back with more information and a repro. See pantsbuild/pants#12831 (comment).Backtrace
Your operating system and version
Ubuntu 21.04, Arch with kernel 5.13.13-arch1-1
Your Python version (
python --version)3.7, 3.9
Your Rust version (
rustc --version)1.57.0
Your PyO3 version
0.15.1
How did you install python? Did you use a virtualenv?
Inside a virtualenv, but retrieved via system-relevant package managers.
Additional Info
No response
The text was updated successfully, but these errors were encountered: