Re: [PyQt] Freezes and crashes with signal autoconnection
Phil Thompson-5 wrote: I had to replace ImageLink arguments in signal definition with 'PyQt_PyObject', not sure why exactly) Neither am I. Else I would get the following message: TypeError: type 'classobj' is not supported as a pyqtSignal() type argument type which is funny because the documentation seems to imply that any object can be passed as a signal argument. It might have something to do with the metatype mechanism, although this is yet another PyQt part that is totally obscure to me. The bug is this line in get_param()... res = ulist.first() ...which returns the first string in the list and *not* a copy of the first string in the list. The result is that you are still using it after Qt has destroyed it. This behaviour is horribly un-Pythonic but allowed (so I can't change it as doing so might break other people's code). Change the line to... res = ulist[0] ...and it should be Ok. Ok it looks like it *does* work now. I think it's too bad but ok to keep the weird behavior for backward compatibility, but at least please someone write a note about it in the documentation! This bug was horrendous with no erorr message, no stack trace and a seemingly random occurrence, hence my feeling that it should have be related to multi-threading. I would never have been able to solve it by myself. Anyway everything seems to work fine now. Thanks a lot for your kind support and patience! Chris -- View this message in context: http://old.nabble.com/Freezes-and-crashes-with-signal-autoconnection-tp25716493p26842898.html Sent from the PyQt mailing list archive at Nabble.com. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Freezes and crashes with signal autoconnection
On Tue, 8 Dec 2009 14:10:50 -0800 (PST), Christian Roche christian.roche...@gmail.com wrote: Hi Phil, thanks for the detailed explanation, although I have to admit I have a bit of a hard time following through.. Anyway... Phil Thompson-5 wrote: I've already suggested that you should simplify your ImageLink class so that it does not derive from QObject. Okay but there must be something else here, I did just what you suggested http://old.nabble.com/file/p26701730/main.py here (I had to replace ImageLink arguments in signal definition with 'PyQt_PyObject', not sure why exactly) Neither am I. Still I get the same crash, after a few get_param iterations though, which makes me believe it's not a pure GC'ed object issue : If you'd simplified the example further - got rid of the thread, got rid of the GUI, got rid of the connection you'd see that the problem is related to the URL processing. The bug is this line in get_param()... res = ulist.first() ...which returns the first string in the list and *not* a copy of the first string in the list. The result is that you are still using it after Qt has destroyed it. This behaviour is horribly un-Pythonic but allowed (so I can't change it as doing so might break other people's code). Change the line to... res = ulist[0] ...and it should be Ok. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Freezes and crashes with signal autoconnection
On Mon, 7 Dec 2009 16:24:19 -0800 (PST), Christian Roche christian.roche...@gmail.com wrote: However now I have another problem. Following Phill latest advice, I read the following part of the documentation: In the current version QVariant.userType() will correctly return QMetaType.QObjectStar (or QMetaType.QWidgetStar) but an extra reference to the Python object is not kept. To avoid a potential crash you should ensure that you keep a separate reference to the Python object, either explicitly or implicitly by giving it a parent. Unfortunaltely these sentences are totally unclear to me. When is QVariant.userType() used? Who does or does not keep a reference to the Python object, and when? In which situation would a crash potentially occur? When a value is passed between threads Qt wraps it in a QVariant and uses the event system to send it to the correct thread. PyQt can convert any Python object to a QVariant. If possible it uses the standard QVariant types to do so. This means that if the code using the value is C++ then it has a chance of working. The original Python object gets discarded, ie. it's reference count is left unchanged. This is fine because the standard QVariant types (with a couple of exceptions) are value types (as opposed to pointer types) so they can be safely copied by Qt and exist independently of the original Python object. Other Python objects do not correspond to the standard QVariant types, so PyQt has an internal C++ class that can wrap a Python object and can itself be wrapped in a QVariant. As a QVariant can be copied around inside Qt the internal PyQt class manages the reference count of the Python object it is wrapping so that it stays alive for as long as it is needed, and garbage collected when it is not. All the above happens automatically. The problem is that the QObjectStar and QWidgetStar types are pointer types and not value types. If the value being pointed to is owned by Python then it's important that the reference count is maintained, otherwise the QObject/QWidget will be destroyed when the Python object is garbage collected and the QVariant will be left with a dangling pointer and will cause a crash. Ideally these types would be wrapped by the same internal PyQt class which would manage the reference count. The problem is that any C++ code that is expecting a QObjectStar/QWidgetStar wouldn't know how to get it out of the wrapper. The main use case is making Python objects available as JavaScript objects in QtScript. Therefore, in these specific cases, if it necessary for your code to ensure that there is an explicit reference kept to any QObject or QWidget you are passing between threads. Worse, eventhough I don't understand the why, I tried to implement the how, i.e., naively added the following lines to my code, hoping to have given my poor lonesome QObject some parent by doing so, and not any ordinary parent, the parent of all parents, the very QApplication itself: class ImageLink(QObject): def __init__(self, base, url, href): QObject.__init__(self) app = QApplication.instance() self.moveToThread(app.thread()) self.setParent(app) blah blah Alas, poor Yorich, all this no no avail. Still it crashes faster than the lightning, and grieves my sore heart and my tired soul. I've already suggested that you should simplify your ImageLink class so that it does not derive from QObject. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Freezes and crashes with signal autoconnection
Hi Phil, thanks for the detailed explanation, although I have to admit I have a bit of a hard time following through.. Anyway... Phil Thompson-5 wrote: I've already suggested that you should simplify your ImageLink class so that it does not derive from QObject. Okay but there must be something else here, I did just what you suggested http://old.nabble.com/file/p26701730/main.py here (I had to replace ImageLink arguments in signal definition with 'PyQt_PyObject', not sure why exactly) Still I get the same crash, after a few get_param iterations though, which makes me believe it's not a pure GC'ed object issue : python main.py get_param(http://abcdef.net/st/st.php?id=6630script=1url=http://g.ftv.com/4/17/377889p=60, url) get_param(http://g.ftv.com/4/17/377889, url) [1]3510 segmentation fault (core dumped) python main.py gdb /usr/bin/python core.3510 Program terminated with signal 11, Segmentation fault. #0 0x00247ef9 in qpycore_PyObject_FromQString (qs...@0x9346a5c) at qpycore_qstring.cpp:49 49 if ((obj = PyUnicode_FromUnicode(NULL, qstr.length())) == NULL) (gdb) bt #0 0x00247ef9 in qpycore_PyObject_FromQString (qs...@0x9346a5c) at qpycore_qstring.cpp:49 #1 0x001964b9 in slot_QString___str__ (sipSelf=0xb747450c) at sip/QtCore/qstring.sip:449 #2 0x03644edf in _PyObject_Str (v=0xb747450c) at Objects/object.c:415 #3 0x03654c16 in PyString_Format (format=0xb77df320, args=0xb77e306c) at Objects/stringobject.c:4839 #4 0x03655e1f in string_mod (v=0x2b2a2928, w=0xb77e306c) at Objects/stringobject.c:4116 [blah blah blah] Thanks, Chris -- View this message in context: http://old.nabble.com/Freezes-and-crashes-with-signal-autoconnection-tp25716493p26701730.html Sent from the PyQt mailing list archive at Nabble.com. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Freezes and crashes with signal autoconnection
Hi Phill, Hans, thanks a lot for your answers. Hans-Peter Jansen-2 wrote: This does NOT qualify as a small piece of code, because: - it's convoluted code (e.g. it's not obvious, which part runs threaded) - you're doing hard to track things with QUrls (this is, where it crashes) Well let's say it was the smallest sample I was able to come up with, taking into account the fact that I still do not clearly understand what's wrong with the code and why or where precisely it crashes. So I'm basically going blind here. Hans-Peter Jansen-2 wrote: Your clue stick is called gdb [...] eh voilà, your code crashes in the QUrl ctor. Easy, isn't it. This procedure should help you to isolate your issue. Yes I was able to get similar results doing it slightly differently, I would remove limits on coredumpsize in shell ulimit -c unlimited then obtain a core.xyz corefile during the crash and debug it using gdb /usr/bin/python core.xyz which would give me the same backtrace. However as Phil noted earlier it's still difficult to see what's wrong here. In particular, all the print statements I could add to my code to debug QUrl manipulation would always indicate perfectly well-formed QUrl objects. There's something else going wrong here, that has to do with the asynchronous garbage collection of Python and C++ objects from what I understand, but here halts my insight. Hans-Peter Jansen-2 wrote: Doing silly things in Qt results in this behavior, and PyQt cannot not protect you here, while it adds some obstacles inherited from Python semantics (e.g. lifetime issues). Ok but what exaclty am I doing wrong ? From my point of view the intent is clear: I manage some lists (QListView) of ImageLink that I want populated by worker threads (QThread). So I launch QThreads that create and set up ImageLink objects locally and then pass them over when ready to the main thread using PyQt signals. All this seems reasonnable at first sight and the documentation doesn't warn against doing that kind of things as much as I can tell. The first problem I encountered was due to the fact that the ImageLink instance passed in the signal does not contain a reference to the original ImageLink python object, so the latter could be GC'ed if the sending thread ended before the signal was delivered. Hence the need to use the Qt.BlockingQueuedConnection mode in this particular case, which solves the problem. However now I have another problem. Following Phill latest advice, I read the following part of the documentation: In the current version QVariant.userType() will correctly return QMetaType.QObjectStar (or QMetaType.QWidgetStar) but an extra reference to the Python object is not kept. To avoid a potential crash you should ensure that you keep a separate reference to the Python object, either explicitly or implicitly by giving it a parent. Unfortunaltely these sentences are totally unclear to me. When is QVariant.userType() used? Who does or does not keep a reference to the Python object, and when? In which situation would a crash potentially occur? Worse, eventhough I don't understand the why, I tried to implement the how, i.e., naively added the following lines to my code, hoping to have given my poor lonesome QObject some parent by doing so, and not any ordinary parent, the parent of all parents, the very QApplication itself: class ImageLink(QObject): def __init__(self, base, url, href): QObject.__init__(self) app = QApplication.instance() self.moveToThread(app.thread()) self.setParent(app) blah blah Alas, poor Yorich, all this no no avail. Still it crashes faster than the lightning, and grieves my sore heart and my tired soul. Hans-Peter Jansen-2 wrote: OTOH, it's a small price to pay for using the most efficient and versatile toolkit out there with Python. Well far form me the idea of belitteling the quality of the Qt and/or PyQt frameworks, I'm not an experienced programmer in general and definitely not in the domain of GUIs. However I feel that eventhough the concept is probably beautiful, the code is still evolving fast (read: still not mature) and most of all the documentation is quite succint. In any case I still do not understand the damn issue, so as always... any help greatly appreciated ! :-) Chris -- View this message in context: http://old.nabble.com/Freezes-and-crashes-with-signal-autoconnection-tp25716493p26686774.html Sent from the PyQt mailing list archive at Nabble.com. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Freezes and crashes with signal autoconnection
On Thursday 03 December 2009, 02:09:36 Christian Roche wrote: Phil Thompson-5 wrote: Either way people need a small, self-contained example that demonstrates the problem. Hi Phil, I think I've been able to isolate a small piece of code that consistently reproduces the problem. http://old.nabble.com/file/p26619445/main.py This does NOT qualify as a small piece of code, because: - it's convoluted code (e.g. it's not obvious, which part runs threaded) - you're doing hard to track things with QUrls (this is, where it crashes) This piece of code displays a gray rectangle on my system and systematically crashes when I click on it. My config is as follows: qt-4.5.3-9.fc11.i586.rpm PyQt4-4.5.4-1.fc11.i586.rpm sip-4.8.2-1.fc11.i586.rpm I'd be very interested in understanding what's wrong here because i've been strugling for weeks with incomprehensible crashes that seem to come out of nowhere and I've not the single clue what's going on. Your clue stick is called gdb, but you need to prepare your system accordingly, e.g. need to install debuginfo packages of Qt, sip and PyQt beforehand. Then run: gdb python -ex 'set args main.py' -ex run Click on the image, and: Starting program: main.py [Thread debugging using libthread_db enabled] [New Thread 0xb5c85b90 (LWP 4686)] [Thread 0xb5c85b90 (LWP 4686) exited] Program received signal SIGSEGV, Segmentation fault. 0xb783c49a in QUrl (this=0xb5305630, u...@0xb530b3ec) at io/qurl.cpp:3907 3907if (!url.isEmpty()) Current language: auto; currently c++ (gdb) bt #0 0xb783c49a in QUrl (this=0xb5305630, u...@0xb530b3ec) at io/qurl.cpp:3907 #1 0xb7a436bc in init_QUrl (sipArgs=0x8145ecc, sipArgsParsed=0xbfffb6f0) at sipQtCoreQUrl.cpp:2576 #2 0xb799edc7 in sipSimpleWrapper_init (self=0x815e8cc, args=0x8145ecc, kwds=0x0) at siplib.c:7945 #3 0xb7ebc9b5 in type_call (type=value optimized out, args=0x8145ecc, kwds=0x0) at Objects/typeobject.c:745 #4 0xb7e6bc1c in PyObject_Call (func=0x80dcd9c, arg=0x8145ecc, kw=0x0) at Objects/abstract.c:2487 #5 0xb7ef6d20 in PyEval_EvalFrameEx (f=0xb530b734, throwflag=0) at Python/ceval.c:3890 #6 0xb7ef623d in PyEval_EvalFrameEx (f=0xb530b15c, throwflag=0) at Python/ceval.c:3765 #7 0xb7ef623d in PyEval_EvalFrameEx (f=0xb530aff4, throwflag=0) at Python/ceval.c:3765 #8 0xb7efbb9b in PyEval_EvalCodeEx (co=0xb7c3b3c8, globals=0xb7c7902c, locals=0x0, args=0xb7c463f8, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2942 #9 0xb7e90a29 in function_call (func=0xb7bbce2c, arg=0xb7c463ec, kw=0x0) at Objects/funcobject.c:524 #10 0xb7e6bc1c in PyObject_Call (func=0xb7bbce2c, arg=0xb7c463ec, kw=0x0) at Objects/abstract.c:2487 #11 0xb7e799fe in instancemethod_call (func=0xb7bbce2c, arg=0xb7c463ec, kw=0x0) at Objects/classobject.c:2579 #12 0xb7e6bc1c in PyObject_Call (func=0xb7c2984c, arg=0x8145d0c, kw=0x0) at Objects/abstract.c:2487 #13 0xb7ef474f in PyEval_CallObjectWithKeywords (func=0xb7c2984c, arg=0x8145d0c, kw=0x0) at Python/ceval.c:3548 #14 0xb79a0933 in sip_api_call_method (isErr=0x0, method=0xb7c2984c, fmt=0xb723e007 D) at siplib.c:1534 #15 0xb6d57679 in sipVH_QtGui_27 (sipGILState=PyGILState_UNLOCKED, sipMethod=0xb7c2984c, a0=0xbfffcc48) at sipQtGuicmodule.cpp:7057 #16 0xb6fe4239 in sipQListView::mouseReleaseEvent (this=0x820cce8, a0=0xbfffcc48) at sipQtGuiQListView.cpp:763 #17 0xb62b7363 in QWidget::event (this=0x820cce8, event=0xbfffcc48) at kernel/qwidget.cpp:7554 #18 0xb66479b3 in QFrame::event (this=0x820cce8, e=0xbfffcc48) at widgets/qframe.cpp:559 #19 0xb66e6c7f in QAbstractScrollArea::viewportEvent (this=0x820cce8, e=0xb531) at widgets/qabstractscrollarea.cpp:962 #20 0xb6799567 in QAbstractItemView::viewportEvent (this=0x820cce8, event=0xbfffcc48) at itemviews/qabstractitemview.cpp:1476 #21 0xb6fdd70f in sipQListView::viewportEvent (this=0x820cce8, a0=0xbfffcc48) at sipQtGuiQListView.cpp:1371 #22 0xb66e9285 in QAbstractScrollAreaFilter::eventFilter (this=0x820e250, o=0x820cb10, e=0xbfffcc48) at widgets/qabstractscrollarea_p.h:100 #23 0xb7882b0a in QCoreApplicationPrivate::sendThroughObjectEventFilters (this=0x8196878, receiver=0x820cb10, event=0xbfffcc48) at kernel/qcoreapplication.cpp:726 #24 0xb626074a in QApplicationPrivate::notify_helper (this=0x8196878, receiver=0x820cb10, e=0xbfffcc48) at kernel/qapplication.cpp:4061 #25 0xb62693d1 in QApplication::notify (this=0x8196858, receiver=0x820cb10, e=0xbfffcc48) at kernel/qapplication.cpp:3767 #26 0xb71bb4ce in sipQApplication::notify (this=0x8196858, a0=0x820cb10, a1=0xbfffcc48) at sipQtGuiQApplication.cpp:309 #27 0xb78838fb in QCoreApplication::notifyInternal (this=0x8196858, receiver=0x820cb10, event=0xbfffcc48) at kernel/qcoreapplication.cpp:610 #28 0xb626843e in QApplicationPrivate::sendMouseEvent (receiver=0x820cb10, event=0xbfffcc48, alienWidget=0x820cb10, nativeWidget=0x81e8090, buttonDown=0xb6ac9a20,
Re: [PyQt] Freezes and crashes with signal autoconnection
On Wed, 2 Dec 2009 17:09:36 -0800 (PST), Christian Roche christian.roche...@gmail.com wrote: Phil Thompson-5 wrote: Either way people need a small, self-contained example that demonstrates the problem. Hi Phil, I think I've been able to isolate a small piece of code that consistently reproduces the problem. http://old.nabble.com/file/p26619445/main.py This piece of code displays a gray rectangle on my system and systematically crashes when I click on it. My config is as follows: qt-4.5.3-9.fc11.i586.rpm PyQt4-4.5.4-1.fc11.i586.rpm sip-4.8.2-1.fc11.i586.rpm I'd be very interested in understanding what's wrong here because i've been strugling for weeks with incomprehensible crashes that seem to come out of nowhere and I've not the single clue what's going on. You might want to look at the last paragraph of... http://www.riverbankcomputing.com/static/Docs/PyQt4/pyqt4ref.html#qvariant ...as it seems to apply to your ImageLink type. I'd suggest changing the design so that you are passing something simpler than a QObject between threads. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Freezes and crashes with signal autoconnection
Phil Thompson-5 wrote: Either way people need a small, self-contained example that demonstrates the problem. Hi Phil, I think I've been able to isolate a small piece of code that consistently reproduces the problem. http://old.nabble.com/file/p26619445/main.py This piece of code displays a gray rectangle on my system and systematically crashes when I click on it. My config is as follows: qt-4.5.3-9.fc11.i586.rpm PyQt4-4.5.4-1.fc11.i586.rpm sip-4.8.2-1.fc11.i586.rpm I'd be very interested in understanding what's wrong here because i've been strugling for weeks with incomprehensible crashes that seem to come out of nowhere and I've not the single clue what's going on. Thanks for your support, Chris -- View this message in context: http://old.nabble.com/Freezes-and-crashes-with-signal-autoconnection-tp25716493p26619445.html Sent from the PyQt mailing list archive at Nabble.com. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Freezes and crashes with signal autoconnection
On Wed, 25 Nov 2009 15:27:33 -0800 (PST), Christian Roche christian.roche...@gmail.com wrote: Hi there, so what should I do about this issue? Should I file a bug report? Or is it only me? The PyQt4 version I'm using is fairly recent however it crashes A LOT! What gives? Most likely a bug in your application. Any bug can only be fixed if it can be reproduced by somebody else, or if the code is sufficiently small that the problem can be identified by just reading it. Either way people need a small, self-contained example that demonstrates the problem. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Freezes and crashes with signal autoconnection
Hi there, so what should I do about this issue? Should I file a bug report? Or is it only me? The PyQt4 version I'm using is fairly recent however it crashes A LOT! What gives? Thanks for your help, Chris -- View this message in context: http://old.nabble.com/Freezes-and-crashes-with-signal-autoconnection-tp25716493p26522132.html Sent from the PyQt mailing list archive at Nabble.com. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Freezes and crashes with signal autoconnection
Hi Phil, Phil Thompson-5 wrote: I thought you were using current snapshots (where the code that was crashing was only compiled in with old versions of Qt). I've just tried against the latest snapshots (sip-4.9.2-snapshot-20091115.tar.gz and PyQt-x11-gpl-4.6.2-snapshot-20091115.tar.gz) however the results are even worse; the application crashes very quickly with the following trace. I suspect it might be related to the installation, however the demos seem to work ok. - Program terminated with signal 11, Segmentation fault. #0 memcpy () at ../sysdeps/i386/i686/memcpy.S:75 in ../sysdeps/i386/i686/memcpy.S Missing separate debuginfos, use: debuginfo-install OpenEXR-libs-1.6.1-8.fc11.i586 e2fsprogs-libs-1.41.4-12.fc11.i586 fontconfig-2.7.1-1.fc11.i586 freetype-2.3.9-5.fc11.i586 ilmbase-1.0.1-4.fc11.i586 jasper-libs-1.900.1-13.fc11.i586 kdelibs-4.3.2-4.fc11.i586 keyutils-libs-1.2-5.fc11.i586 krb5-libs-1.6.3-20.fc11.i586 lcms-libs-1.18-2.fc11.i586 libICE-1.0.4-7.fc11.i586 libSM-1.1.0-4.fc11.i586 libXau-1.0.4-5.fc11.i586 libXcursor-1.1.9-4.fc11.i586 libXdamage-1.1.1-6.fc11.i586 libXfixes-4.0.3-5.fc11.i586 libXi-1.2.1-1.fc11.i586 libXinerama-1.0.3-4.fc11.i586 libXrandr-1.2.99.4-3.fc11.i586 libXrender-0.9.4-5.fc11.i586 libXxf86vm-1.0.2-2.fc11.i586 libattr-2.4.43-3.fc11.i586 libcap-2.16-4.fc11.1.i586 libdrm-2.4.11-2.fc11.i586 libgcrypt-1.4.4-6.fc11.i586 libgpg-error-1.6-3.i586 libjpeg-6b-45.fc11.i586 libmng-1.0.10-2.fc11.i586 libpng-1.2.37-1.fc11.i586 libselinux-2.0.80-1.fc11.i586 libtiff-3.8.2-14.fc11.i586 libxcb-1.2-4.fc11.i586 linuxwacom-0.8.2.2-11.fc11.i586 phonon-4.3.1-102.fc11.i586 qt-x11-4.5.3-9.fc11.i586 xz-libs-4.999.9-0.1.beta.20091007git.fc11.i586 (gdb) bt #0 memcpy () at ../sysdeps/i386/i686/memcpy.S:75 #1 0xb66020d8 in ?? () #2 0x01a0b7a7 in QString::append (this=0xb6621000, s...@0x9ee9490) at /usr/include/bits/string3.h:52 #3 0x04506e8d in QString::operator+= (s=value optimized out, this=value optimized out) at ../../src/corelib/tools/qstring.h:269 #4 QTextCursor::insertText (s=value optimized out, this=value optimized out) at text/qtextcursor.cpp:1307 #5 0x04507312 in QTextCursor::insertText (this=0xbfeac73c, te...@0xb66020d8) at text/qtextcursor.cpp:1275 #6 0x04499c71 in QTextControlPrivate::append (this=0x9d4ead0, te...@0xb66020d8, format=Qt::AutoText) at text/qtextcontrol.cpp:2740 #7 0x04499dd3 in QTextControl::append (this=0x9d4eac0, te...@0xb66020d8) at text/qtextcontrol.cpp:2754 #8 0x04702459 in QTextEdit::append (this=0x9d4d4f0, te...@0xb66020d8) at widgets/qtextedit.cpp:2597 #9 0x011e3149 in meth_QTextEdit_append (sipSelf=0x9bdd3ac, sipArgs=0x9bdebcc) at sipQtGuiQTextEdit.cpp:3381 #10 0x03641762 in PyCFunction_Call (func=0x9be5fcc, arg=0x9bdebcc, kw=0x0) at Objects/methodobject.c:81 #11 0x0369d5be in call_function (oparg=value optimized out, pp_stack=value optimized out) at Python/ceval.c:3679 #12 PyEval_EvalFrameEx (oparg=value optimized out, pp_stack=value optimized out) at Python/ceval.c:2370 #13 0x0369ed79 in PyEval_EvalCodeEx (co=0xb781aad0, globals=0xb786e02c, locals=0x0, args=0x9b7d078, argcount=2, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2942 #14 0x0362db87 in function_call (func=0x9be2294, arg=0x9b7d06c, kw=0x0) at Objects/funcobject.c:524 #15 0x0360172c in PyObject_Call (func=0x9be2294, arg=0x9b7d06c, kw=0x0) at Objects/abstract.c:2487 #16 0x03617284 in instancemethod_call (func=0xb73b189c, arg=0x9b7d06c, kw=0x0) at Objects/classobject.c:2579 #17 0x0360172c in PyObject_Call (func=0xb73b189c, arg=0x9bdeb4c, kw=0x0) at Objects/abstract.c:2487 #18 0x03697f14 in PyEval_CallObjectWithKeywords (func=0xb73b189c, arg=0x9bdeb4c, kw=0x0) at Python/ceval.c:3548 #19 0x003ba2ff in ?? () from /usr/lib/python2.6/site-packages/sip.so #20 0xb73b189c in ?? () #21 0x09bdeb4c in ?? () #22 0x in ?? () Current language: auto; currently asm - -- View this message in context: http://old.nabble.com/Freezes-and-crashes-with-signal-autoconnection-tp25716493p2667.html Sent from the PyQt mailing list archive at Nabble.com. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Freezes and crashes with signal autoconnection
Hi Phil, Phil Thompson-5 wrote: It's difficult to see how this would crash if everything else (ie. Python and Qt) is working as it should. However it does imply you are using a very old version of Qt (v4.1). what leads you to think to an old version is used ? In fact this should really not be the case, here are the packages installed on my system: qt-4.5.3-9.fc11.i586 PyQt4-4.5.4-1.fc11.i586 sip-4.8.2-1.fc11.i586 PyKDE4-4.3.2-1.fc11.i586 It could be that python were using an old pyqt version laying around but I doubt it. Here is the list of libraries I have on my system: ls -1 /usr/lib/libQt* /usr/lib/libQt3Support_debug.so /usr/lib/libQt3Support.prl /usr/lib/libQt3Support.so /usr/lib/libQt3Support.so.4 /usr/lib/libQt3Support.so.4.5 /usr/lib/libQt3Support.so.4.5.3 /usr/lib/libQtAssistantClient_debug.so /usr/lib/libQtAssistantClient.prl /usr/lib/libQtAssistantClient.so /usr/lib/libQtAssistantClient.so.4 /usr/lib/libQtAssistantClient.so.4.5 /usr/lib/libQtAssistantClient.so.4.5.3 /usr/lib/libQtCLucene_debug.so /usr/lib/libQtCLucene.prl /usr/lib/libQtCLucene.so /usr/lib/libQtCLucene.so.4 /usr/lib/libQtCLucene.so.4.5 /usr/lib/libQtCLucene.so.4.5.3 /usr/lib/libQtCore_debug.so /usr/lib/libQtCore.prl /usr/lib/libQtCore.so /usr/lib/libQtCore.so.4 /usr/lib/libQtCore.so.4.5 /usr/lib/libQtCore.so.4.5.3 /usr/lib/libQtDBus_debug.so /usr/lib/libQtDBus.prl /usr/lib/libQtDBus.so /usr/lib/libQtDBus.so.4 /usr/lib/libQtDBus.so.4.5 /usr/lib/libQtDBus.so.4.5.3 /usr/lib/libQtDesignerComponents_debug.so /usr/lib/libQtDesignerComponents.prl /usr/lib/libQtDesignerComponents.so /usr/lib/libQtDesignerComponents.so.4 /usr/lib/libQtDesignerComponents.so.4.5 /usr/lib/libQtDesignerComponents.so.4.5.3 /usr/lib/libQtDesigner_debug.so /usr/lib/libQtDesigner.prl /usr/lib/libQtDesigner.so /usr/lib/libQtDesigner.so.4 /usr/lib/libQtDesigner.so.4.5 /usr/lib/libQtDesigner.so.4.5.3 /usr/lib/libQtGui_debug.so /usr/lib/libQtGui.prl /usr/lib/libQtGui.so /usr/lib/libQtGui.so.4 /usr/lib/libQtGui.so.4.5 /usr/lib/libQtGui.so.4.5.3 /usr/lib/libQtHelp_debug.so /usr/lib/libQtHelp.prl /usr/lib/libQtHelp.so /usr/lib/libQtHelp.so.4 /usr/lib/libQtHelp.so.4.5 /usr/lib/libQtHelp.so.4.5.3 /usr/lib/libQtNetwork_debug.so /usr/lib/libQtNetwork.prl /usr/lib/libQtNetwork.so /usr/lib/libQtNetwork.so.4 /usr/lib/libQtNetwork.so.4.5 /usr/lib/libQtNetwork.so.4.5.3 /usr/lib/libQtOpenGL_debug.so /usr/lib/libQtOpenGL.prl /usr/lib/libQtOpenGL.so /usr/lib/libQtOpenGL.so.4 /usr/lib/libQtOpenGL.so.4.5 /usr/lib/libQtOpenGL.so.4.5.3 /usr/lib/libQtScript_debug.so /usr/lib/libQtScript.prl /usr/lib/libQtScript.so /usr/lib/libQtScript.so.4 /usr/lib/libQtScript.so.4.5 /usr/lib/libQtScript.so.4.5.3 /usr/lib/libQtScriptTools_debug.so /usr/lib/libQtScriptTools.prl /usr/lib/libQtScriptTools.so /usr/lib/libQtScriptTools.so.4 /usr/lib/libQtScriptTools.so.4.5 /usr/lib/libQtScriptTools.so.4.5.3 /usr/lib/libQtSql_debug.so /usr/lib/libQtSql.prl /usr/lib/libQtSql.so /usr/lib/libQtSql.so.4 /usr/lib/libQtSql.so.4.5 /usr/lib/libQtSql.so.4.5.3 /usr/lib/libQtSvg_debug.so /usr/lib/libQtSvg.prl /usr/lib/libQtSvg.so /usr/lib/libQtSvg.so.4 /usr/lib/libQtSvg.so.4.5 /usr/lib/libQtSvg.so.4.5.3 /usr/lib/libQtTest_debug.so /usr/lib/libQtTest.prl /usr/lib/libQtTest.so /usr/lib/libQtTest.so.4 /usr/lib/libQtTest.so.4.5 /usr/lib/libQtTest.so.4.5.3 /usr/lib/libQtUiTools.a /usr/lib/libQtUiTools_debug.a /usr/lib/libQtUiTools.prl /usr/lib/libQtWebKit_debug.so /usr/lib/libQtWebKit.prl /usr/lib/libQtWebKit.so /usr/lib/libQtWebKit.so.4 /usr/lib/libQtWebKit.so.4.5 /usr/lib/libQtWebKit.so.4.5.3 /usr/lib/libQtXml_debug.so /usr/lib/libQtXmlPatterns_debug.so /usr/lib/libQtXmlPatterns.prl /usr/lib/libQtXmlPatterns.so /usr/lib/libQtXmlPatterns.so.4 /usr/lib/libQtXmlPatterns.so.4.5 /usr/lib/libQtXmlPatterns.so.4.5.3 /usr/lib/libQtXml.prl
Re: [PyQt] Freezes and crashes with signal autoconnection
On Wed, 18 Nov 2009 09:22:25 -0800 (PST), Christian Roche christian.roche...@gmail.com wrote: Hi Phil, Phil Thompson-5 wrote: It's difficult to see how this would crash if everything else (ie. Python and Qt) is working as it should. However it does imply you are using a very old version of Qt (v4.1). what leads you to think to an old version is used ? In fact this should really not be the case, here are the packages installed on my system: qt-4.5.3-9.fc11.i586 PyQt4-4.5.4-1.fc11.i586 sip-4.8.2-1.fc11.i586 PyKDE4-4.3.2-1.fc11.i586 I thought you were using current snapshots (where the code that was crashing was only compiled in with old versions of Qt). Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Freezes and crashes with signal autoconnection
On Sat, 14 Nov 2009 05:22:41 -0800 (PST), Christian Roche christian.roche...@gmail.com wrote: Hi again; Phil Thompson-5 wrote: I can't remember if you are using snapshots or not, but there are some issues fixed related to looking up Python reimplementations of virtual methods. forget about Windows. The whole thing crashes so quick on Windows XP that I can't even get a glimpse of the main window. I'm using the latest build (PyQt-Py2.6-gpl-4.6.1-1.exe) but not snapshots as I can't compile there. I'd be willing to compile a build there and also get debugger feedback but I would need a pointer on some resource on how to do that on Windows. Back on Linux I also get crashes although much less frequently. The difference is that I'm able to get some feedback from the system in that case so it might prove a bit more useful! Here is the backtrace of a random crash that appears to occur when a thread calls the QUrl.resolved() method. This is with PyQt4-4.5.4-1 and sip-4.8.2. - Program terminated with signal 11, Segmentation fault. #0 0x082c0f23 in qpycore_PyObject_FromQString (qs...@0xb5bd21b8) at qpycore_qstring.cpp:55 55 *pyu++ = (qstr.at(i)).unicode(); It's difficult to see how this would crash if everything else (ie. Python and Qt) is working as it should. However it does imply you are using a very old version of Qt (v4.1). Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Freezes and crashes with signal autoconnection
Hi again; Phil Thompson-5 wrote: I can't remember if you are using snapshots or not, but there are some issues fixed related to looking up Python reimplementations of virtual methods. forget about Windows. The whole thing crashes so quick on Windows XP that I can't even get a glimpse of the main window. I'm using the latest build (PyQt-Py2.6-gpl-4.6.1-1.exe) but not snapshots as I can't compile there. I'd be willing to compile a build there and also get debugger feedback but I would need a pointer on some resource on how to do that on Windows. Back on Linux I also get crashes although much less frequently. The difference is that I'm able to get some feedback from the system in that case so it might prove a bit more useful! Here is the backtrace of a random crash that appears to occur when a thread calls the QUrl.resolved() method. This is with PyQt4-4.5.4-1 and sip-4.8.2. - Program terminated with signal 11, Segmentation fault. #0 0x082c0f23 in qpycore_PyObject_FromQString (qs...@0xb5bd21b8) at qpycore_qstring.cpp:55 55 *pyu++ = (qstr.at(i)).unicode(); (gdb) bt #0 0x082c0f23 in qpycore_PyObject_FromQString (qs...@0xb5bd21b8) at qpycore_qstring.cpp:55 #1 0x0820f4b9 in slot_QString___str__ (sipSelf=0xb2f21f2c) at sip/QtCore/qstring.sip:449 #2 0x03644e04 in PyObject_Unicode (v=0xb2f21f2c) at Objects/object.c:522 #3 0x036791eb in PyUnicodeUCS4_Format (format=0x901dda0, args=0xb2f21f2c) at Objects/unicodeobject.c:8649 #4 0x03655a92 in PyString_Format (format=0x901dda0, args=0xb2f21f2c) at Objects/stringobject.c:5090 #5 0x03655e1f in string_mod (v=0x901dc68, w=0xb2f21f2c) at Objects/stringobject.c:4116 #6 0x03602d03 in binary_op1 (v=0xb7487b20, w=0xb2f21f2c, op_slot=16) at Objects/abstract.c:914 #7 0x0360382b in binary_op (v=0xb7487b20, w=0x0, op_slot=16, op_name=0x36e02c2 %) at Objects/abstract.c:966 #8 0x03699afe in PyEval_EvalFrameEx (f=0xb5bd2364, throwflag=0) at Python/ceval.c:1152 #9 0x0369df0d in fast_function (nk=value optimized out, na=value optimized out, n=value optimized out, pp_stack=value optimized out, func=value optimized out) at Python/ceval.c:3765 #10 call_function (nk=value optimized out, na=value optimized out, n=value optimized out, pp_stack=value optimized out, func=value optimized out) at Python/ceval.c:3700 #11 PyEval_EvalFrameEx (nk=value optimized out, na=value optimized out, n=value optimized out, pp_stack=value optimized out, func=value optimized out) at Python/ceval.c:2370 #12 0x0369ed79 in PyEval_EvalCodeEx (co=0x8e2eec0, globals=0x8ec52d4, locals=0x0, args=0x91b6e78, argcount=1, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2942 #13 0x0362db87 in function_call (func=0x912ffb4, arg=0x91b6e6c, kw=0x0) at Objects/funcobject.c:524 #14 0x0360172c in PyObject_Call (func=0x912ffb4, arg=0x91b6e6c, kw=0x0) at Objects/abstract.c:2487 #15 0x03617284 in instancemethod_call (func=0xb6783af4, arg=0x91b6e6c, kw=0x0) at Objects/classobject.c:2579 #16 0x0360172c in PyObject_Call (func=0xb6783af4, arg=0xb784f02c, kw=0x0) at Objects/abstract.c:2487 #17 0x03697f14 in PyEval_CallObjectWithKeywords (func=0xb6783af4, arg=0xb784f02c, kw=0x0) at Python/ceval.c:3548 #18 0x00603963 in PyDict_New () at Objects/dictobject.c:224 #19 0x081c7860 in sipVH_QtCore_5 (sipGILState=PyGILState_LOCKED, sipMethod=0xb6783af4) at sipQtCorecmodule.cpp:3763 #20 0x081f233c in sipQThread::run (this=0x9503a28) at sipQtCoreQThread.cpp:215 #21 0x001af2c2 in QThreadPrivate::start (arg=0x9503a28) at thread/qthread_unix.cpp:188 #22 0x00984935 in start_thread (arg=0xb1afdb70) at pthread_create.c:297 #23 0x008b994e in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 --- Chris -- View this message in context: http://old.nabble.com/Freezes-and-crashes-with-signal-autoconnection-tp25716493p26349989.html Sent from the PyQt mailing list archive at Nabble.com. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Freezes and crashes with signal autoconnection
On Fri, 16 Oct 2009 13:41:44 -0700 (PDT), Christian Roche christian.roche...@gmail.com wrote: Hi again! Phil Thompson-5 wrote: If you have a list of the QThread instances you can scan the list when finished() is received to see which one it is. There is an obvious race condition with that approach. I don't know if this race condition is obvious but I'm personally unable to identify it. Could you please kindly elaborate a bit for a multi-threading newbie ? :-) If two threads finish at the same time you may not be able to identify which is which. Phil Thompson-5 wrote: You could define a method in your QThread sub-class that finished() is connect to. That method just emits another signal but with the QThread instance as an argument. I also have a hard time understanding this one. How could finished() connect to a method in the originating thread, which by definition is supposed not to exist anymore since it has emitted this very signal? Or is the semantics for this signal more complex? I think you are confusing the QThread and the thread itself. The former will still exist when the latter has finished. By the way, I applied the first approach you suggested, i.e., I use Qt.BlockingQueuedConnection when passing arguments in signals from threads to main, and I now have a slot that collects finished() signals, browse the list of threads and deletes those that it finds effectively finished. The behavior is definitely better on Linux, although not perfect, however on Windows I still get lots of crashes with no error messages at all. Sometimes, but not always, the application spurts some weird error messages in the middle of the run, not right before the crash, like NotImplementedError: QAbstractListModel.rowCount() is abstract and must be overridden although this method is overriden of course, and works most of the time; or (the application is using shelve): Traceback (most recent call last): File E:\Python\gallery\gallery\gallery.py, line 107, in data return QVariant(self.getLink(index).getPixmap()) File E:\Python\gallery\gallery\threads.py, line 76, in getPixmap filepath = imageCache.getImageFile(self) File E:\Python\gallery\gallery\threads.py, line 148, in getImageFile if self.cache.has_key(url): File E:\Programs\Python\lib\shelve.py, line 107, in has_key return key in self.dict File E:\Programs\Python\lib\_abcoll.py, line 329, in __contains__ self[key] File E:\Programs\Python\lib\bsddb\__init__.py, line 266, in __getitem__ self._checkOpen() AttributeError: 'str' object has no attribute '_checkOpen' or simply (this one arrives right before the crash): NotImplementedError It all seems to be related to the ImageLink instances emitting a signal towards a QAbstractListModel layoutChanged signal once download is complete. I have no problem when I remove this signal (except of course that the display does not refresh -() However this all happens in the main thread as far as I can tell. I'm going to try and extract a use case for that one but I'm afraid it won't be easy. In the meantime if you could point me to a possible likely cause I'd be very grateful! I can't remember if you are using snapshots or not, but there are some issues fixed related to looking up Python reimplementations of virtual methods. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Freezes and crashes with signal autoconnection
Hi again! Phil Thompson-5 wrote: If you have a list of the QThread instances you can scan the list when finished() is received to see which one it is. There is an obvious race condition with that approach. I don't know if this race condition is obvious but I'm personally unable to identify it. Could you please kindly elaborate a bit for a multi-threading newbie ? :-) Phil Thompson-5 wrote: You could define a method in your QThread sub-class that finished() is connect to. That method just emits another signal but with the QThread instance as an argument. I also have a hard time understanding this one. How could finished() connect to a method in the originating thread, which by definition is supposed not to exist anymore since it has emitted this very signal? Or is the semantics for this signal more complex? By the way, I applied the first approach you suggested, i.e., I use Qt.BlockingQueuedConnection when passing arguments in signals from threads to main, and I now have a slot that collects finished() signals, browse the list of threads and deletes those that it finds effectively finished. The behavior is definitely better on Linux, although not perfect, however on Windows I still get lots of crashes with no error messages at all. Sometimes, but not always, the application spurts some weird error messages in the middle of the run, not right before the crash, like NotImplementedError: QAbstractListModel.rowCount() is abstract and must be overridden although this method is overriden of course, and works most of the time; or (the application is using shelve): Traceback (most recent call last): File E:\Python\gallery\gallery\gallery.py, line 107, in data return QVariant(self.getLink(index).getPixmap()) File E:\Python\gallery\gallery\threads.py, line 76, in getPixmap filepath = imageCache.getImageFile(self) File E:\Python\gallery\gallery\threads.py, line 148, in getImageFile if self.cache.has_key(url): File E:\Programs\Python\lib\shelve.py, line 107, in has_key return key in self.dict File E:\Programs\Python\lib\_abcoll.py, line 329, in __contains__ self[key] File E:\Programs\Python\lib\bsddb\__init__.py, line 266, in __getitem__ self._checkOpen() AttributeError: 'str' object has no attribute '_checkOpen' or simply (this one arrives right before the crash): NotImplementedError It all seems to be related to the ImageLink instances emitting a signal towards a QAbstractListModel layoutChanged signal once download is complete. I have no problem when I remove this signal (except of course that the display does not refresh -() However this all happens in the main thread as far as I can tell. I'm going to try and extract a use case for that one but I'm afraid it won't be easy. In the meantime if you could point me to a possible likely cause I'd be very grateful! Thanks again for your help! Chris -- View this message in context: http://www.nabble.com/Freezes-and-crashes-with-signal-autoconnection-tp25716493p25932041.html Sent from the PyQt mailing list archive at Nabble.com. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Freezes and crashes with signal autoconnection
On Sun, 11 Oct 2009 14:36:37 -0700 (PDT), Christian Roche christian.roche...@gmail.com wrote: Phil Thompson-5 wrote: Can you try with the latest installer (though it does contain a nasty thread-related regression). Do you have a test case? Phil Hi Phil, I'm currently using PyQt 4.6-1 with Python 2.6.3. I think I've been able to isolate a http://www.nabble.com/file/p25847873/main.py test case that crashes consistently and demonstrates at least one of the problems I've been experiencing with PyQt multithreading. In this piece of code, when the time delay in the GalleryCreator thread is greater than the delay in the GalleryModel appendLink slot, the application works fine. However if this delay is set to a value less than the latter, then it crashes after a few iterations. It seems that the QAbstractListModel object doesn't like it when a queue of pending events is forming, with custom data types. Also in the second case, the application won't crash if you use Qt.BlockingQueuedConnection instead of AutoConnection (see line 111). This makes sense since in that case no event queue is forming, the Model object has enough time to consume the incoming event before a new one is posted. The application won't crash either if you use 'PyQt_PyObject' instead of ImageLink in the signal argument (see line 88). Don't ask me why :-) Note: I see a similar behaviour on Linux. I think this is all one problem and is nothing to do with threads. There is a (necessary) change of behaviour (documented in the current snapshot) when wrapping a Python sub-class of a QObject in a QVariant. Previously this was first wrapped in a PyQt_PyObject which managed the reference counts for you so that you didn't need to maintain an explicit reference to the QObject sub-class (the ImageLink instance in your case). The problem with that is that nothing outside of PyQt knows what a PyQt_PyObject is. So C++ code that has a slot or a dynamic property expecting a QObject*. The current behaviour means that you can pass your ImageLink instance around to code that doesn't know anything about Python - but it means it won't manage the reference count for you. In your example your ImageLink instance is being garbage collected too soon. Using a blocking connection serialises access to it making sure that it is used before being garbage collected. Using PyQt_PyObject as the signal signature has the effect of enforcing the previous behaviour. Hence no crash in either case. Phil ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Freezes and crashes with signal autoconnection
Phil Thompson-5 wrote: I think this is all one problem and is nothing to do with threads. There is a (necessary) change of behaviour (documented in the current snapshot) when wrapping a Python sub-class of a QObject in a QVariant. Previously this was first wrapped in a PyQt_PyObject which managed the reference counts for you so that you didn't need to maintain an explicit reference to the QObject sub-class (the ImageLink instance in your case). The problem with that is that nothing outside of PyQt knows what a PyQt_PyObject is. So C++ code that has a slot or a dynamic property expecting a QObject*. The current behaviour means that you can pass your ImageLink instance around to code that doesn't know anything about Python - but it means it won't manage the reference count for you. In your example your ImageLink instance is being garbage collected too soon. Using a blocking connection serialises access to it making sure that it is used before being garbage collected. Using PyQt_PyObject as the signal signature has the effect of enforcing the previous behaviour. Hence no crash in either case. Phil Hi Phil, thanks a lot for the explanation, it all makes sense. However I've not been able to fully test it because I bumped into another issue: so now thanks to using Qt.BlockingQueuedConnection, my QThread instances send a signal and wait when they have finished, so the destination slot has time to process the ImageLink parameter. But I cannot keep track of the active threads in this slot anymore. Previously I would do thread = QThread(link) threadList[link] = thread when creating a new QThread and threadList[link].wait() del threadList[link] in the termination slot, in order to keep the necessary references to the existing threads. But now since my threads are blocked, I cannot forget them in this slot. So I tried to create a new slot onto which I would connect the finished() signal; at that time I'm sure that the thread is gone, but how can I identify which one? There's no parameter to the signal, and trying to get a reference to the emiting thread by using self.sender() doesn't work either, I guess because precisely the thread is gone for good at that point. So how am I supposed to keep track of those running threads in this situation ? Or am i totally off ? Thanks a lot for your help! Chris -- View this message in context: http://www.nabble.com/Freezes-and-crashes-with-signal-autoconnection-tp25716493p25884077.html Sent from the PyQt mailing list archive at Nabble.com. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[PyQt] Freezes and crashes with signal autoconnection
Hi there, I'm having some problems with a fairly simple multi-threaded application under PyQt 4.5.4 and Windows XP. I have a number of worker threads that feed one consumer in the main GUI thread. Initially I had the worker threads directly call the add method of the consumer object; this piece of code was protected by a mutex. So in short: class Worker(QThread): def run(self): ... cache.add(link) class Cache(): def add(self, link): mutex.lock() # Add link to queue mutex.unlock() cache = Cache() This works pretty well but still I'm not completely satisfied. It's bad to execute code that doesn't belong to your thread, right? So I tried to replace that with a signal/slot mechanism: class Worker(QThread): addLink = pyqtSignal(Link) def init(self): self.addLink.connect(cache.add) def run(self): ... link = Link(blah blah) self.addLink.emit(link) class Cache(QObject): def add(self, link): # Add link to queue # No more mutex since access is now serial, right ? ... However the application freezes after a while. No more GUI activity, window not even repainting anymore and Windows tells me this application is not responding etc when trying to close. This doesn't happen if I use Qt.DirectConnection or Qt.BlockingQueuedConnection it seems, although I have no idea why. I also notice that with Qt.AutoConnection, the application crashes with no error message unless I use 'PyQt_PyObject' types, with the quotes, in all signal definitions (instead of Link for instance); I don't have this problem either when using Qt.DirectConnection or Qt.BlockingQueuedConnection. So does anyone understand what's going on here under the hood? Is the signal/slot approach the correct way to garantee serial access to a shared resource between threads (the link queue in this example)? Why is this whole thing crashing and freezing like that? Thanks for sharing your insight! Chris -- View this message in context: http://www.nabble.com/Freezes-and-crashes-with-signal-autoconnection-tp25716493p25716493.html Sent from the PyQt mailing list archive at Nabble.com. ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
Re: [PyQt] Freezes and crashes with signal autoconnection
On Mon, 5 Oct 2009 02:24:09 -0700 (PDT), Christian Roche christian.roche...@gmail.com wrote: Hi there, I'm having some problems with a fairly simple multi-threaded application under PyQt 4.5.4 and Windows XP. I have a number of worker threads that feed one consumer in the main GUI thread. Initially I had the worker threads directly call the add method of the consumer object; this piece of code was protected by a mutex. So in short: class Worker(QThread): def run(self): ... cache.add(link) class Cache(): def add(self, link): mutex.lock() # Add link to queue mutex.unlock() cache = Cache() This works pretty well but still I'm not completely satisfied. It's bad to execute code that doesn't belong to your thread, right? So I tried to replace that with a signal/slot mechanism: class Worker(QThread): addLink = pyqtSignal(Link) def init(self): self.addLink.connect(cache.add) def run(self): ... link = Link(blah blah) self.addLink.emit(link) class Cache(QObject): def add(self, link): # Add link to queue # No more mutex since access is now serial, right ? ... However the application freezes after a while. No more GUI activity, window not even repainting anymore and Windows tells me this application is not responding etc when trying to close. This doesn't happen if I use Qt.DirectConnection or Qt.BlockingQueuedConnection it seems, although I have no idea why. This rings a bell - I think with something I replied on the mailing list not too long ago. Something about Qt seemingly not doing the right thing when AutoConnection is used. But I can't remember the details (or find the message). I also notice that with Qt.AutoConnection, the application crashes with no error message unless I use 'PyQt_PyObject' types, with the quotes, in all signal definitions (instead of Link for instance); I don't have this problem either when using Qt.DirectConnection or Qt.BlockingQueuedConnection. So does anyone understand what's going on here under the hood? Is the signal/slot approach the correct way to garantee serial access to a shared resource between threads (the link queue in this example)? Why is this whole thing crashing and freezing like that? Can you try with the latest installer (though it does contain a nasty thread-related regression). Do you have a test case? Phil Chris ___ PyQt mailing listPyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
