[PyQt] Segfault on PyQt 5.9.1 on Windows

[Phil Thompson]

On 17 Nov 2017, at 4:44 pm, Valentin Valls <valentin.valls at esrf.fr> wrote:
> 
> Hi,
> 
> I am trying to debug a software on Windows using the last PyQt.
> 
> I compile all the expected libraries in debug mode
> 
> - cpython 3.6
> - PyQt 5.9.1
> - Qt 5.9.2
> - sip 4.19.5
> 
> As result this following code often create segfault in release mode
> (using the last release from pypi), and an infinite loop in debug mode.
> 
> from PyQt5 import Qt
> qapp = Qt.QApplication([])
> Qt.QThreadPool.globalInstance()
> # the problem occurs when you exist the python interpreter
> 
> The infinite loop is on the SIP side: objmap.c line 102:
> 
>    while ((hek = om -> hash_array[hash].key) != NULL && hek != key)
>        hash = (hash + inc) % om -> size;
> 
> Here is the backtrace:
> 
>    sip_d.pyd!findHashEntry(sipObjectMap * om, void * key) Line 103    C
>    sip_d.pyd!sipOMFindObject(sipObjectMap * om, void * key, const
> _sipTypeDef * td) Line 116    C
>    sip_d.pyd!sip_api_get_pyobject(void * cppPtr, const _sipTypeDef *
> td) Line 8934    C
>    QtCore_d.pyd!PyQtMonitor::on_destroyed(QObject * cppInst) Line
> 106    C++
>    QtCore_d.pyd!PyQtMonitor::qt_static_metacall(QObject * _o,
> QMetaObject::Call _c, int _id, void * * _a) Line 75    C++
>    Qt5Cored.dll!QMetaObject::activate(QObject * sender, int
> signalOffset, int local_signal_index, void * * argv) Line 3768    C++
>    Qt5Cored.dll!QMetaObject::activate(QObject * sender, const
> QMetaObject * m, int local_signal_index, void * * argv) Line 3629    C++
>    Qt5Cored.dll!QObject::destroyed(QObject * _t1) Line 216    C++
>    Qt5Cored.dll!QObject::~QObject() Line 901    C++
>    Qt5Cored.dll!QThreadPool::~QThreadPool() Line 448    C++
>    [External Code]   
>    python36_d.dll!Py_Exit(int sts) Line 1551    C
>    python36_d.dll!handle_system_exit() Line 604    C
>    python36_d.dll!PyErr_PrintEx(int set_sys_last_vars) Line 614    C
>    python36_d.dll!PyErr_Print() Line 509    C
>    python36_d.dll!PyRun_InteractiveOneObject(_iobuf * fp, _object *
> filename, PyCompilerFlags * flags) Line 237    C
>    python36_d.dll!PyRun_InteractiveLoopFlags(_iobuf * fp, const char *
> filename_str, PyCompilerFlags * flags) Line 112    C
>    python36_d.dll!PyRun_AnyFileExFlags(_iobuf * fp, const char *
> filename, int closeit, PyCompilerFlags * flags) Line 74    C
>    python36_d.dll!run_file(_iobuf * fp, const wchar_t * filename,
> PyCompilerFlags * p_cf) Line 338    C
>    python36_d.dll!Py_Main(int argc, wchar_t * * argv) Line 809    C
>    python_d.exe!wmain(int argc, wchar_t * * argv) Line 15    C
>    [External Code]   
> 
> The global thread pool is then not usable.
> 
> I also have segfault and deadlock when using an own QThreadPool; i suspect
> Qt.QIcon(filename) to have a strange behaviour when it is released at the
> end of the program; and segfault when reusing 2 time index created by createIndex
> from custom QAbstractItemModel.
> Here (https://github.com/silx-kit/silx/pull/1344
> ) is the different tweaks i used to be able to have no segfault
> in our continuous integration tests.
> But right now i don't have simple reproducible examples.
> 
> Anyway, is the use of the globalInstance is reproducible on your side?
> Do you have any idea?
> Hope this feedback can help. Thanks a lot.

I've made a change in tonight's PyQt snapshot which may fix the problem.

Phil