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. _______________________________________________ pypy-issue mailing list pypy-issue@python.org https://mail.python.org/mailman/listinfo/pypy-issue
