Fatal Python error: PyGILState_Release

[sondrelg]

Hi!

When testing my pyo3 + pyo3-asyncio library built with maturin I've run into the following:

Fatal Python error: PyGILState_Release: thread state 0x7f1e840332c0 must be current when releasing
Python runtime state: finalizing (tstate=0x00005575cd335710)

Thread 0x00007f1e8a7c0740 (most recent call first):
  <no Python frame>
/home/runner/work/_temp/e4644e7f-3d00-4cab-9d0c-bcd97e7a8[27](https://github.com/sondrelg/self-limiters/actions/runs/3224315473/jobs/5275320799#step:10:28)0.sh: line 3:  [28](https://github.com/sondrelg/self-limiters/actions/runs/3224315473/jobs/5275320799#step:10:29)64 Aborted                 (core dumped) python bench.py s --count 100 --iterations 30 --target 3.5

Googling the relevant parts of the error doesn't really help. Any idea where to start debugging this?

Opened this as a discussion instead of an issue, since I'm not sure it's related to maturin 🤷 I was using maturin develop here though. Will try to see if the issue replicates when using a release build.

[messense]

I don't think it's related to maturin, it might be related to pyo3 or pyo3-asyncio, I'm going to transfer this to pyo3.

Does it always reproduce or it only occurs sometimes? The failed action you referred to only failed on Python 3.10, did it ever fail on other Python versions?

[messense]

I'm unable to reproduce the issue on pyo3 0.17.2 after many tries, maybe it's already fixed?

[sondrelg]

This run should be using 0.17.2 I believe. I'm flying the next 12 hours, but will try to reproduce more then!

[messense]

With a bit of luck I just got one for pyo3 0.17.2 locally: https://gist.github.com/messense/8cb0e20f67a83a2758b96080006a4735

It's a bit different than pyo3 0.16, no more Fatal Python error: PyGILState_Release: thread state 0x7f1e840332c0 must be current when releasing, only a segfault.

(gdb) up
#3  0x00007fe7ce98364b in pyo3_ffi::object::Py_DECREF (op=0x7fe7cecd2890) at /root/.cargo/registry/src/git.luolix.top-1ecc6299db9ec823/pyo3-ffi-0.17.2/src/object.rs:427
427	            _Py_Dealloc(op)
(gdb) p op
$1 = (*mut pyo3_ffi::object::PyObject) 0x7fe7cecd2890
(gdb) p *op
$2 = pyo3_ffi::object::PyObject {ob_refcnt: 0, ob_type: 0x55ab060ddba0 <PyTuple_Type>}

[davidhewitt]

Hmm, there's not anything which obviously sticks out to me there. The tuple is created by PyO3 using only types which we should have correct implementations for.

It smells a bit like possible heap corruption somewhere else in the program. Can you try running with an address sanitiser and see what happens? E.g. in PyO3 we can run our tests with sanitiser like so:

pyo3/noxfile.py

Line 224 in 43261c7

@nox.session(name="address-sanitizer", venv_backend="none")

[sondrelg]

Sorry I just remembered this was still open. The package had some lua scripts it would load at runtime, and after inlining those lua scripts this hasn't happened since - not sure if that's helpful 🙂

I'm happy to leave this for now, it might not be related to pyo3 after all