The tp_clear handler of the module object calls a custom clear function if the PyModuleDef.m_clear field is set. This function can set an exception which will be leaked to the garbage collector. An exception in tp_clear is not expected and caused a crash in the garbage collector. In the master branch it will cause just writing a traceback to stderr (see ), but in any case it would be better to handle the failure locally in the module's tp_clear.
I'm not sure what tp_clear should do in this situation. Other than propagating the exception to the GC, the most reasonable behavior seems to be to write the exception to stderr and ignore it -- but I think having the GC do that would be more robust. IOW, I think raising an exception from tp_clear is reasonable, and if that caused (causes?) a crash, it's a bug.
I've attached a reproduction case. Here's the setup.py that I used: ``` from distutils.core import Extension, setup extension = Extension("breaky", ["breaky.c"]) setup( name="tp_clear", version="0.1.0", ext_modules=[extension], ) ``` which I built and ran with: ``` python setup.py build_ext --inplace python -c "import breaky, gc; a = breaky.Breaky(); a = 1" ```
I've just realised that this issue was specific to tp_clear on a module and not on objects. tp_clear on modules has already been fixed in https://bugs.python.org/issue33622. I think this is closable.
