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 list [email protected] http://www.riverbankcomputing.com/mailman/listinfo/pyqt
