[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pykde
Subject:    Re: [PyQt] Deadlock in 5.9.1
From:       Phil Thompson <phil () riverbankcomputing ! com>
Date:       2017-10-31 16:16:15
Message-ID: 251DAA2D-30DA-4C04-A5A5-1C38BD5E5C4A () riverbankcomputing ! com
[Download RAW message or body]

On 26 Oct 2017, at 5:15 pm, Milorad Pop-Tosic <pop@hiri.com> wrote:
> 
> Hi, 
> 
> We're still experiencing this deadlock in PyQt 5.9. It manifests itself as the \
> application being frozen. We haven't been able to produce a test case which \
> faithfully reproduces the problem since it looks like a timing issue. We got the \
> stack traces below when we attached to the frozen process with GDB on Linux. 
> The stack trace indicates that the main thread got stuck in QObject.connect in \
> PyQtMonitor::monitor which was apparently added in 5.9. At the same time, the \
> worker thread is in a QObject destructor. Any ideas?

Can you try tonight's snapshot or the attached patch?

Phil


["deadlock.patch" (deadlock.patch)]

diff -r f2ddcf108add qpy/QtCore/qpycore_event_handlers.cpp
--- a/qpy/QtCore/qpycore_event_handlers.cpp	Sat Oct 07 15:32:32 2017 +0100
+++ b/qpy/QtCore/qpycore_event_handlers.cpp	Tue Oct 31 16:14:31 2017 +0000
@@ -60,8 +60,10 @@
     // to monitoring.  Note that subsequently calling disconnect() would cause
     // a crash - this is why we keep a separate record of C++ instances
     // currently being monitored and never explicitly disconnect the monitor.
+    Py_BEGIN_ALLOW_THREADS
     connect(cppInst, SIGNAL(destroyed(QObject *)),
             SLOT(on_destroyed(QObject *)), Qt::UniqueConnection);
+    Py_END_ALLOW_THREADS
 }
 
 

[Attachment #4 (text/plain)]

_______________________________________________
PyQt mailing list    PyQt@riverbankcomputing.com
https://www.riverbankcomputing.com/mailman/listinfo/pyqt

[prev in list] [next in list] [prev in thread] [next in thread]