[PySide] Issues with threads after updating to PySide/shiboken 5.14.2

icfwm at gmx.net icfwm at gmx.net
Mon Apr 20 13:08:37 CEST 2020


--- sorry, forgot to reply also to mailing list ---

Hi Christian,

thanks for the quick response. I don't have a lot of time at the moment,
but I tried to run the script and indeed it does crash for me. However,
I think I am at the latest version from the pypi repository:
PS C:\temp> .\test_pyside\Scripts\pip freeze
PySide2==5.14.2
shiboken2==5.14.2

I would expect that the version 5.14.2 does not change its contents
"under the hood", bugfixes would certainly result in a 5.14.3 or
5.14.2.1 or similar? As you can see I'm on windows, using a minimal
winpython release of 3.7.4 and a virtual environment just for this test.

PS C:\temp> .\test_pyside\Scripts\python.exe pyside813.py
Qt 5.14.2 (x86_64-little_endian-llp64 shared (dynamic) release build; by
MSVC 2017)
3.7.4 (tags/v3.7.4:e09359112e, Jul 8 2019, 20:34:20) [MSC v.1916 64 bit
(AMD64)]

Launching 10 threads, emitting 0xAC1D...
> exec()
#0 Sender emitting 0xAC1D
#1 Sender emitting 0xAC1D
#2 Sender emitting 0xAC1D
#3 Sender emitting 0xAC1D
#4 Sender emitting 0xAC1D
#5 Sender emitting 0xAC1D
#6 Sender emitting 0xAC1D
#7 Sender emitting 0xAC1D
#8 Sender emitting 0xAC1D
#9 Sender emitting 0xAC1D
#10 Sender emitting 0xAC1D
#11 Sender emitting 0xAC1D
#12 Sender emitting 0xAC1D
#13 Sender emitting 0xAC1D
#14 Sender emitting 0xAC1D
#15 Sender emitting 0xAC1D
#16 Sender emitting 0xAC1D
#17 Sender emitting 0xAC1D
#18 Sender emitting 0xAC1D
#19 Sender emitting 0xAC1D
#20 Sender emitting 0xAC1D
#21 Sender emitting 0xAC1D
#22 Sender emitting 0xAC1D
#23 Sender emitting 0xAC1D
#24 Sender emitting 0xAC1D
#25 Sender emitting 0xAC1D
#26 Sender emitting 0xAC1D
#27 Sender emitting 0xAC1D
#28 Sender emitting 0xAC1D
#29 Sender emitting 0xAC1D
#30 Sender emitting 0xAC1D
#31 Sender emitting 0xAC1D
#32 Sender emitting 0xAC1D
#33 Sender emitting 0xAC1D
#34 Sender emitting 0xAC1D
#35 Sender emitting 0xAC1D
#36 Sender emitting 0xAC1D
#37 Sender emitting 0xAC1D
#38 Sender emitting 0xAC1D
#39 Sender emitting 0xAC1D
#40 Sender emitting 0xAC1D
#41 Sender emitting 0xAC1D
#42 Sender emitting 0xAC1D
#43 Sender emitting 0xAC1D
#44 Sender emitting 0xAC1D
#45 Sender emitting 0xAC1D
#46 Sender emitting 0xAC1D
#47 Sender emitting 0xAC1D
#48 Sender emitting 0xAC1D
#49 Sender emitting 0xAC1D
#50 Sender emitting 0xAC1D
#51 Sender emitting 0xAC1D
#52 Sender emitting 0xAC1D
#53 Sender emitting 0xAC1D
#54 Sender emitting 0xAC1D
#55 Sender emitting 0xAC1D
#56 Sender emitting 0xAC1D
#57 Sender emitting 0xAC1D
#58 Sender emitting 0x8D4000003A

After this, I get the crash dialog. Let me know if I can help any further.

Kind Regards
Christoph

> Gesendet: Montag, 20. April 2020 um 12:04 Uhr
> Von: "Christian Tismer" <tismer at stackless.com>
> An: icfwm at gmx.net, pyside at qt-project.org
> Betreff: Re: [PySide] Issues with threads after updating to
> PySide/shiboken 5.14.2
>
> Hi Christoph,
>
> On 19.04.20 13:27, icfwm at gmx.net wrote:
> ...
>
> > Updating to PySide/shiboken 5.14.2 forced me to set allow-threads to
> > true or auto for the c++ library wrapper since the default setting
> > introduced dead-locking, probably due to the way the inter-thread
> > communication has been implemented. Afterwards, everything seemed to
> > work, but I am observing infrequent, hard-to-reproduce crashes,
> > sometimes showing stack traces full of python3 / PySide / shiboken2
> > functions with neither of my own code nor shiboken wrappers of the
> > c++ library in it. Sometimes stack traces seem to indicate that
> > QSharedPointers are deleted too early while there are still active
> > references.
> > > Configuring the application to use only one thread heals the crashes.
> > Going back to 5.14.1 using exactly same python, c++, and
> > typesystem.xml doesn't show crashes as well, even when using multiple
> > threads.
> ...
>
> Are you sure that you really have the freshest version of 5.14.2? There
> have been updates, so I want to make sure that we are talking of the
> right version.
>
> We have admittedly made a few heavy changes with some impact on threads.
>
> For one, we removed the auto-allowing threads because PYSIDE-803 became
> *unreactive*. The many allow-threads were bad, because each one costs
> one 5ms cycle on the GIL carousel when there are computing threads.
>
> So this maybe was a bit too much. allow-threads should come in two
> flavours:
> "We must allow threads or we get a hang"
> and
> "We should allow threads when this computes too long"
> Unfortunately we don't have such a distinction.
>
> The first one is essential, while the second one got less urgent or even
> counter-productive, because computers became much faster, but the 5ms
> carousel was never adapted, accoudingly. I think Python should change
> the default.
>
> So that was for PYSIDE-803. The consequences still need adjustment.
>
> Observing random crashes was a thing that was tackled in PYSIDE-813/164.
> Because PYSIDE-164 added allow-threads to avoid a blocking problem,
> there popped PYSIDE-813 up: When using many threads that sent messages
> to each other, then we got random crashes. After a long search, this
> turned out to be a race condition where somebody thought that he could
> Py_INCREF a variable without holding the GIL. He can not!
>
> So it is possibly already solved and you need to update, or maybe there
> is another such case hiding somewhere.
>
> To be sure, you could run this program:
> https://bugreports.qt.io/secure/attachment/92459/pyside813.py
>
> If this does not crash, then we know that you have a new bug :-)
>
> Ciao -- Chris
> -- Christian Tismer-Sperling :^) tismer at stackless.com
> Software Consulting : http://www.stackless.com/
> Strandstraße 37 : https://github.com/PySide
> 24217 Schönberg : GPG key -> 0xFB7BEE0E
> phone +49 173 24 18 776 fax +49 (30) 700143-0023
>


More information about the PySide mailing list