Bug 49216 – [Qt] Crash when calling QWebFrame::setUrl() while a previous load has pending requests

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKit Qt

[Volker Grabsch]

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"));

[Markus Goetz]

Do you have a backtrace of the segfault?

[Markus Goetz]

(In case this is a Qt bug, we can re-open http://bugreports.qt.nokia.com/browse/QTBUG-15122 )

[Volker Grabsch]

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.

[Andreas Kling]

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.

[Antti Koivisto]

Simply clearing the document pointer in CachedResourceLoader destructor before canceling might fix this.

[Andreas Kling]

Created attachment 82721 [details]
Proposed patch

[Andreas Kling]

*** Bug 39670 has been marked as a duplicate of this bug. ***

[Antti Koivisto]

Comment on attachment 82721 [details]
Proposed patch

r=me

[Andreas Kling]

Comment on attachment 82721 [details]
Proposed patch

Clearing flags on attachment: 82721

Committed r78816: <http://trac.webkit.org/changeset/78816>

[Andreas Kling]

All reviewed patches have been landed.  Closing bug.

[Andreas Kling]

*** Bug 55467 has been marked as a duplicate of this bug. ***