[PyQt] Re: New crasher

Phil Thompson phil at riverbankcomputing.com
Mon Nov 2 15:53:49 GMT 2009


On Mon, 02 Nov 2009 11:32:28 +0100, Giovanni Bajo <rasky at develer.com>
wrote:
> On Tue, 2009-10-20 at 09:41 +0100, Phil Thompson wrote:
>> On Fri, 16 Oct 2009 19:42:20 +0200, Giovanni Bajo <rasky at develer.com>
>> wrote:
>> > On 10/16/2009 3:38 PM, Phil Thompson wrote:
>> >> On Fri, 16 Oct 2009 15:31:08 +0200, Giovanni Bajo <rasky at develer.com>
>> >> wrote:
>> >>> On 10/16/2009 10:10 AM, Phil Thompson wrote:
>> >>>> All outstanding bug reports against PyQt and SIP have been resolved
>> >>>> -
>> >>>> if
>> >>>> you disagree then let me know.
>> >>>>
>> >>>> I plan to release PyQt v4.6.1 and SIP v4.9.1 early next week.
>> >>>>
>> >>>> BTW, the current PyQt snapshot will build against Qt v4.6-beta1.
>> >>> Hi Phil,
>> >>>
>> >>> I got some GC-related random crashes in a testsuite run after you
>> >>> fixed
>> 
>> >>> the QApplication destruction. I investigated them enough to see that

>> >>> it's related to invokation of focusPolicy() or other focus-related 
>> >>> virtual methods on an already-deleted object, but they are hard to
>> track
>> >>>
>> >>> down and I am not sure whenever I will have a reproduction recipe
>> ready.
>> >>>
>> >>> Is there anything specific to focus stuff that rings a bell to you?
>> >> 
>> >> No. The obvious source of the problem is the QApplication being
>> >> deleted
>> >> too
>> >> soon in relation to some other object.
>> > 
>> > I delete all top-level widgets, flush all the events 
>> > (qApp.processEvents()), and run an explicit gc.collect() pass. I 
>> > actually don't know what else to do...
>> > 
>> > I start to believe that it's a Qt problem rather than a PyQt's one;
eg:
>> >
>> > some globals somewhere in the focus code that is not reset by 
>> > QApplication's destructor and still points to some destroyed object.
>> > 
>> > I'll have a further look.
>> 
>> Any progress? I'd prefer to revert to the existing broken behaviour
>> (which
>> affects almost nobody) than introduce the potential for random
>> crash-on-exit "bugs".
> 
> Hello,
> 
> after having updated to the latest SIP/PyQt versions and having worked
> on this crash, I found out that it is actually unrelated to
> QApplication's destruction. I managed to find a reproduction recipe:
> 
> ====================================================================
> #!/usr/bin/env python
> import sip
> from PyQt4.Qt import *
> app = QApplication([])
> 
> class MyWidget(QWidget):
>     def __init__(self, parent):
>         QWidget.__init__(self, parent)
>         self.cb = QComboBox(self)
>         self.ed = QLineEdit(self)
>         QObject.connect(self.ed, SIGNAL("XXX"), self.update)
>         self.setStyleSheet("UNKNOWN {}")
> 
> for i in range(100):
>     print i
> 
>     dw = QWidget(None)
>     vl = QVBoxLayout(dw)
>     for e in range(10):
>         tp = MyWidget(None)
>         vl.addWidget(tp)
> 
>     for w in dw.findChildren(QWidget):
>         w.focusPolicy()
> 
>     sip.delete(dw)
> ====================================================================
> 
> I think this wins the prize as weirdest bug ever. It randomically
> segfaults on me after a few loops. Remove any line, including the
> setStyleSheet() and it does not crash anymore. The backtrace starts
> with:
> 
> 0xb70d353a in QWidget::focusPolicy () from _qt.so
> 
> I'm on Linux right now, in case it matters, but I first saw this bug on
> Windows on the real application, so I'm positive that this crasher
> crashes on Windows too.
> 
> The latest funny bit I want to share is that it does not segfault nor
> gives any error under valgrind :)

Fixed in tonight's PyQt snapshot. QObject.findChildren() was doing bad
things with the ownership of the objects it was finding.

Thanks,
Phil


More information about the PyQt mailing list