On Thu, 25 Aug 2011 17:18:13 +0200, Erik Janssens <erik.janss...@conceptive.be> wrote: > Hi, > > After lots of tries I have been able to get a stacktrace > + core of a segfault that I believe occurs from time to time. > > The attached stacktrace shows the segfault is inside the QT > event loop, without even involving Python. > > What I believe that happens is this : > > 1) A signal is connected to a slot with a queued connection. > > 2) within PyQtProxy::unislot, the sender() mehtod is > called on a QObject > > 3) the documentation of sender() however states that the > returned pointer is only valid if the sending object has > not been deleted yet. > > I think the segfault occurs because sometimes this object > has been deleted allready, and thus the casting of the > sender object to its type segfaults the application sometimes. > > Best regards and thanks for any view on this. > > Erik
I think the only place PyQt uses the sender (rather than just remembering its value for possible future wrapping as a Python QObject) is in the qobject_cast call at the beginning of PyQtProxy::unislot(). This is only done to support short circuit signals. Assuming you don't use these can you try replacing the cast with 0 so that the if () test always fails? Thanks, Phil _______________________________________________ PyQt mailing list PyQt@riverbankcomputing.com http://www.riverbankcomputing.com/mailman/listinfo/pyqt
