Under certain circumstances, calling setHtml() and then setUrl() on a QWebFrame instance causes a segmentation fault! More specifically, this always happens if the HTML provided to setHtml() contains an image (<img> tag). It doesn't matter whether the image acually exists. No GUI (QWebView) needs to be involved. The following 3 lines of code are sufficient to reproduce this strange bug: QWebPage *page = new QWebPage(); page->mainFrame()->setHtml("<img src=\"dummy:\">"); page->mainFrame()->setUrl(QUrl("about:blank"));
Do you have a backtrace of the segfault?
(In case this is a Qt bug, we can re-open http://bugreports.qt.nokia.com/browse/QTBUG-15122 )
Created attachment 73487 [details] minimal Qt application to reproduce the segmentation fault Unfortunately, the stack trace doesn't provide much information on my system: (gdb) bt #0 0xb6d960b0 in ?? () from /home/vog/work/rentapacs/qt/lib/libQtWebKit.so.4 #1 0xb6be2a4e in ?? () from /home/vog/work/rentapacs/qt/lib/libQtWebKit.so.4 #2 0xb6cf20b2 in ?? () from /home/vog/work/rentapacs/qt/lib/libQtWebKit.so.4 #3 0xb6bdde65 in ?? () from /home/vog/work/rentapacs/qt/lib/libQtWebKit.so.4 #4 0xb6e1891f in ?? () from /home/vog/work/rentapacs/qt/lib/libQtWebKit.so.4 #5 0xb6da718e in ?? () from /home/vog/work/rentapacs/qt/lib/libQtWebKit.so.4 #6 0xb6daf07f in ?? () from /home/vog/work/rentapacs/qt/lib/libQtWebKit.so.4 #7 0xb6fe68e4 in QWebFrame::setUrl () from /home/vog/work/rentapacs/qt/lib/libQtWebKit.so.4 #8 0x08048b38 in main (argc=-1269742464, argv=0x0) at main.cpp:11 That's why I attached a minimal Qt application that contains the mentioned 3 lines of code. That way, anyone interested can reproduce this issue and get a stack trace without any effort - just unpack, qmake, make and run.
What happens here is that when replacing the Document in Frame::setDocument(), the old Document is destroyed, which calls CachedResourceLoader::cancelRequests(), which in turn calls didFail() on all pending requests. CachedResourceRequests::didFail() creates a RefPtr to protect its loader's Document temporarily, but since the Document is already being destroyed, its ref-count is already 0, causing ~RefPtr to double-delete the Document. Bug 23180 introduced the protector RefPtr.
Simply clearing the document pointer in CachedResourceLoader destructor before canceling might fix this.
Created attachment 82721 [details] Proposed patch
*** Bug 39670 has been marked as a duplicate of this bug. ***
Comment on attachment 82721 [details] Proposed patch r=me
Comment on attachment 82721 [details] Proposed patch Clearing flags on attachment: 82721 Committed r78816: <http://trac.webkit.org/changeset/78816>
All reviewed patches have been landed. Closing bug.
*** Bug 55467 has been marked as a duplicate of this bug. ***