PyPy crashes when calling Py_INCREF in tp_dealloc

Issue #2932 new
Omer Katz
created an issue

This is related to #2637.

When a grpc server is destroyed we have a code path that calls Py_INCREF. See While that's being fixed in the Cython extension itself, I was still wondering if it's possible to support this kind of behaviour since it does work on CPython.

Furthermore, the error message does not pinpoint which object is being destroyed:

RPython traceback:
  File "pypy_module_pypyjit.c", line 182, in portal_12
  File "pypy_interpreter_2.c", line 34215, in handle_bytecode__AccessDirect_None
  File "pypy_interpreter_2.c", line 47248, in dispatch_bytecode__AccessDirect_None
*** Invalid usage of a dying CPython object ***

cpyext, the emulation layer, detected that while it is calling
an object's tp_dealloc, the C code calls back a function that
tries to recreate the PyPy version of the object.  Usually it
means that tp_dealloc calls some general PyXxx() API.  It is
a dangerous and potentially buggy thing to do: even in CPython
the PyXxx() function could, in theory, cause a reference to the
object to be taken and stored somewhere, for an amount of time
exceeding tp_dealloc itself.  Afterwards, the object will be
freed, making that reference point to garbage.
>>> PyPy could contain some workaround to still work if
you are lucky, but it is not done so far; better fix the bug in
the CPython extension.

It could be useful to know which type of object is destroyed to aid debugging.

Comments (2)

  1. Armin Rigo

    "It does work on CPython" is generally wrong. A better wording might be "it happens not to crash CPython in the cases we tried to run this code against".

  2. Omer Katz reporter

    Yes you are correct. I'm wondering if there is a way to avoid the crash in this specific case as well. We could postpone destroying the PyPy object if tp_dealloc is defined until it is done executing, couldn't we?

  3. Log in to comment