[PyQt] Segfaults when (dis)connecting signals on deleted QWebFrame

Phil Thompson phil at riverbankcomputing.com
Wed Dec 3 10:02:58 GMT 2014


On 03/12/2014 6:38 am, Florian Bruhin wrote:
> * Phil Thompson <phil at riverbankcomputing.com> [2014-12-02 22:35:25 
> +0000]:
>> On 02/12/2014 7:30 pm, Florian Bruhin wrote:
>> >Hi,
>> >
>> >Some weeks ago I had some issues with segfaults when disconnecting
>> >QWebFrame::contentSizeChanged. I now finally was able to reproduce it
>> >and wrote a little example script which is attached.
>> >
>> >When running it, and after the output (connecting/disconnecting)
>> >begins clicking any link on the page, there's a segfault with the
>> >attached stacktrace. In the wild I've also seen this happen without
>> >actually changing the page, but I can't reliably reproduce that.
>> >
>> >What's going on there? Is this a PyQt or a Qt bug? I'd expect to get a
>> >RuntimeError telling me the underlying object has been deleted by Qt.
>> 
>> You will only get a RuntimeError if PyQt detects that the object has 
>> been
>> deleted. It can only do this if it (rather than Qt) created the 
>> object.
> 
> Thanks, that explains what I'm seeing. I solved it by monitoring the
> QObject::destroyed signal and not disconnecting the signal where the
> objects were destroyed.
> 
> Though that made me curious -- what is the reason PyQt can't just
> connect a slot to QObject::destroyed for each wrapper, which marks the
> underlying object as dead if invoked?

That approach could be added to the existing mechanism (it couldn't 
replace it) for this particular use case. I'll add it to the TODO list 
but not at a high priority as the current behaviour is longstanding and 
reasonably well understood.

Phil


More information about the PyQt mailing list