--- 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" <tis...@stackless.com> > An: ic...@gmx.net, pyside@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, ic...@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 :^) tis...@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 > _______________________________________________ PySide mailing list PySide@qt-project.org https://lists.qt-project.org/listinfo/pyside