<div dir="ltr"><div><span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif">Is there something special wrt to deallocation of the global QAccessibleCache instance upon interpreter exit?  Perhaps related to QObject.destroyed signal connections?<br><br>If I instantiate a particular custom PyQt5 widget as a top-level window that, itself, has lots of child widgets, the interpreter will tend to crash at on exit.  The only reliable method I have found for avoiding this crash is to ensure that no outstanding references to my </font></span><span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif"><span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif">custom widget instance remain and then to issue a gc.collect() call before exiting.<br><br></font></span></font></span></div><div><span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif"><span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif">The PyQt5 docs suggest that I really shouldn't have to worry about on-exit deallocation crashes so long as a module-level reference to my top-level PyQt5 widget exist when exiting the interpreter.  However, I'm experiencing the opposite.  Incidentally, the pySe</font></span></font></span>lf pointer argument to the qpycore_qobject_metaobject call at the top of the stack trace pasted below appears to point to junk.<br><br>Any advice or tips would be great!  Failing that, in the morning, I'm going to try eliminating all references to the QObject.destroyed signal from my code, since I have a feeling connections to that signal are what ~QAccessibleCache is attempting to tear down when the crash occurs.<br></div><div><span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif"><span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif"><br></font></span></font></span></div><span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif"><span style="font-family:monospace,monospace"><font face="arial,helvetica,sans-serif">Stack trace (it is similar on OS X with release builds of PyQt5, cpython, Qt5):<br></font></span></font></span><div><div><div><div><div><span style="font-family:monospace,monospace"><br>QtCore_d.pyd!qpycore_qobject_metaobject(_sipSimpleWrapper * pySelf, _sipTypeDef * base) Line 52    C++<br>QtWidgets_d.pyd!sipQTableView::metaObject() Line 557    C++<br>Qt5Cored.dll!QObject::~QObject() Line 1003    C++<br>Qt5Guid.dll!QAccessibleCache::~QAccessibleCache()    C++<br>Qt5Guid.dll!QAccessibleCache::`vector deleting destructor'(unsigned int)    C++<br>Qt5Guid.dll!``anonymous namespace'::Q_QGS_qAccessibleCache::innerFunction'::`8'::Cleanup::~Cleanup() Line 46    C++<br>Qt5Guid.dll!``anonymous namespace'::Q_QGS_qAccessibleCache::innerFunction'::`9'::`dynamic atexit destructor for 'cleanup''()    C++<br>Qt5Guid.dll!_CRT_INIT(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 416    C<br>Qt5Guid.dll!__DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 522    C<br>Qt5Guid.dll!_DllMainCRTStartup(void * hDllHandle, unsigned long dwReason, void * lpreserved) Line 473    C<br>ntdll.dll!0000000077153a81()    Unknown<br>ntdll.dll!0000000077153890()    Unknown<br>msvcr120d.dll!000007fedf974eeb()    Unknown<br>msvcr120d.dll!000007fedf97595f()    Unknown<br>msvcr120d.dll!000007fedf975986()    Unknown<br>python_d.exe!__tmainCRTStartup() Line 662    C<br>python_d.exe!wmainCRTStartup() Line 466    C<br>kernel32.dll!0000000076f25a4d()    Unknown<br>ntdll.dll!000000007715b831()    Unknown</span><br><br></div><div>Thanks,<br></div><div>Erik<br></div></div></div></div></div></div>