[PyQt] Segfault on PyQt 5.9.1 on Windows

Phil Thompson phil at riverbankcomputing.com
Tue Nov 21 14:52:31 GMT 2017

On 21 Nov 2017, at 2:46 pm, Valentin Valls <valentin.valls at esrf.fr> wrote:
> On 11/21/2017 03:33 PM, Phil Thompson wrote:
>> On 21 Nov 2017, at 1:27 pm, Valentin Valls <valentin.valls at esrf.fr> wrote:
>>> On 11/20/2017 12:25 PM, Valentin Valls wrote:
>>>>> I've made a change in tonight's PyQt snapshot which may fix the problem.
>>>>> Phil
>>> Hi again,
>>> Here is 2 scripts that still deadlock and segfault on Windows with PyQt
>>> 5.9.2.dev1711191441 in debug version.
>>> It also deadlock and segfault on the release version of PyQt.
>>> I start from our segfaulting project and i reduce the source code as
>>> much as possible.
>>> Then i guess some patterns are pointless.
>>> But i hope it can help.
>>> <deadlock6.py><segfault7.py><valentin_valls.vcf>_______________________________________________
>> Although I've only tested on macOS I can't reproduce the segfault. I am using a slight PyQt change (that will be in tonight's snapshot) but I don't think it would make a difference.
> I can confirm it is only a Windows segfault. We are also testing Mac OS
> X and Linux without any problems.
>> Regarding the deadlock, you will have Python code running in threads while the interpreter is being closed down so I'm not surprised there are problems. Calling QThreadPool.waitForDone() at the end of the script fixes that problem.
>> Phil
> I know. But then, should we have to do it for
> Qt.QThreadPool.globalInstance() too, on any application, just in case a
> third party library uses this thread pool?
> In my point of view, at least the global thread pool should just work.
> As it is working in PyQt4 (there is no such deadlock in PyQt4 using the
> same script).

I would say that the behaviour is undefined. If it "works" in PyQt4 then that is just down to luck.


More information about the PyQt mailing list