[PyQt] segmentation faults common when using QWebView

Hans-Peter Jansen hpj at urpla.net
Mon Nov 29 22:36:45 GMT 2010

On Monday 29 November 2010, 23:05:57 Brandon Craig Rhodes wrote:
> "Hans-Peter Jansen" <hpj at urpla.net> writes:
> > Why not trigger the timer from the loadFinished signal. That way,
> > you get the best of both worlds ;)
> That's a good idea!  I promise to try it, just as soon as I can stop
> the script from giving me a segmentation fault every time that I run
> it. :-)
> If no one who has the development version of PyQt4 installed gets the
> chance to try my script, then I should have time on Wednesday to sit
> down and install the alternate development packages and attempt to
> produce a traceback.  But before going through all of that I wanted
> to see if there was something I was obviously doing wrong with
> pointers or something in my code.

$ gdb python
(gdb) set args qtcrash.py
(gdb) run
Starting program: /usr/bin/python qtcrash.py
[Thread debugging using libthread_db enabled]
[New Thread 0xb456bb90 (LWP 10895)]
[New Thread 0xb3a43b90 (LWP 10897)]
div#content > p > a []
div#content > p > a []
div#content > p > a []
div#content > p > a []
div#content > p > a []
div#content > p > a []
div#content > p > a []
div#content > p > a []
div#content > p > a []
div#content > p > a []
div#content > p > a []
div#content > p > a [<PyQt4.QtWebKit.QWebElement object at 0xb48993ac>, <PyQt4.QtWebKit.QWebElement object at 0xb48993e4
div#ferns-info > h2 > a []
div#ferns-info > h2 > a []

Program received signal SIGSEGV, Segmentation fault.
QCoreApplication::postEvent (receiver=0x8218f00, event=0x8304bd0, priority=0) at kernel/qcoreapplication.cpp:1133
1133        QThreadData *data = *pdata;
Current language:  auto; currently c++
(gdb) bt
#0  QCoreApplication::postEvent (receiver=0x8218f00, event=0x8304bd0, priority=0) at kernel/qcoreapplication.cpp:1133
#1  0xb7811eec in QCoreApplication::postEvent (receiver=0x8218f00, event=0x8304bd0) at kernel/qcoreapplication.cpp:1094
#2  0xb7820dd7 in QObject::deleteLater (this=0x8218f00) at kernel/qobject.cpp:2123
#3  0xb55e2203 in WebCore::QNetworkReplyHandler::finish() () from /usr/lib/libQtWebKit.so.4
#4  0xb55e2848 in WebCore::QNetworkReplyHandler::qt_metacall(QMetaObject::Call, int, void**) ()
   from /usr/lib/libQtWebKit.so.4
#5  0xb7815215 in QMetaObject::metacall (object=0x8218f00, cl=QMetaObject::InvokeMetaMethod, idx=5, argv=0xbfffdc88)
    at kernel/qmetaobject.cpp:237
#6  0xb7827e93 in QMetaObject::activate (sender=0x8218f00, m=0xb4b3b46c, local_signal_index=1, argv=0x0)
    at kernel/qobject.cpp:3272
#7  0xb4af8917 in QNetworkReply::finished (this=0x8218f00) at .moc/release-shared/moc_qnetworkreply.cpp:152
#8  0xb4a86eff in QNetworkReplyImplPrivate::finished (this=0x81fd248) at access/qnetworkreplyimpl.cpp:657
#9  0xb4a6a810 in QNetworkAccessBackend::finished (this=0x81fd190) at access/qnetworkaccessbackend.cpp:309
#10 0xb4a712f1 in QNetworkAccessHttpBackend::finished (this=0x81fd190) at access/qnetworkaccesshttpbackend.cpp:338
#11 0xb4a718e4 in QNetworkAccessHttpBackend::replyFinished (this=0x81fd190) at access/qnetworkaccesshttpbackend.cpp:773
#12 0xb4a86c49 in QNetworkReplyImplPrivate::handleNotifications (this=0x81fd248) at access/qnetworkreplyimpl.cpp:367
#13 0xb4a86ce6 in QNetworkReplyImpl::event (this=0x8218f00, e=0x8207550) at access/qnetworkreplyimpl.cpp:867
#14 0xb631ce6c in QApplicationPrivate::notify_helper (this=0x816a6c8, receiver=0x8218f00, e=0x8207550)
    at kernel/qapplication.cpp:4445
#15 0xb6327786 in QApplication::notify (this=0x812bba8, receiver=0x8218f00, e=0x8207550)
    at kernel/qapplication.cpp:3845
#16 0xb724902e in sipQApplication::notify (this=0x812bba8, a0=0x8218f00, a1=0x8207550)
    at QtGui/sipQtGuiQApplication.cpp:297
#17 0xb780f33b in QCoreApplication::notifyInternal (this=0x812bba8, receiver=0x8218f00, event=0x8207550)
    at kernel/qcoreapplication.cpp:732
#18 0xb78121d8 in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x816a7b0)
    at kernel/qcoreapplication.h:215
#19 0xb781236d in QCoreApplication::sendPostedEvents (receiver=0x0, event_type=0) at kernel/qcoreapplication.cpp:1266
#20 0xb783ee64 in postEventSourceDispatch (s=0x8184110) at kernel/qcoreapplication.h:220
#21 0xb7516998 in g_main_context_dispatch () from /usr/lib/libglib-2.0.so.0
#22 0xb751a203 in g_main_context_iterate () from /usr/lib/libglib-2.0.so.0
#23 0xb751a388 in g_main_context_iteration () from /usr/lib/libglib-2.0.so.0
#24 0xb783e971 in QEventDispatcherGlib::processEvents (this=0x8181e38, flags={i = -1073748792})

I've added some debug calls to prove my claim, and as you can see, it 
crashes in callback2 now after my modifications (that wait for callback1
to finish). Hence, it suffers from the same problem as it doesn't wait 
there for the load finishing again..

-------------- next part --------------
A non-text attachment was scrubbed...
Name: qtcrash.py
Type: application/x-python
Size: 1950 bytes
Desc: not available
URL: <http://www.riverbankcomputing.com/pipermail/pyqt/attachments/20101129/8c517e1b/attachment-0001.bin>

More information about the PyQt mailing list