[pypy-issue] Issue #2932: PyPy crashes when calling Py_INCREF in tp_dealloc (pypy/pypy)

[Omer Katz]

New issue 2932: PyPy crashes when calling Py_INCREF in tp_dealloc
https://bitbucket.org/pypy/pypy/issues/2932/pypy-crashes-when-calling-py_incref-in

Omer Katz:

This is related to #2637.

When a grpc server is destroyed we have a code path that calls Py_INCREF. See https://github.com/grpc/grpc/blob/master/src/python/grpcio/grpc/_cython/_cygrpc/server.pyx.pxi#L99
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.