RESOLVED FIXED 30385
[Qt] QGLauncher crashes while closing a window
https://bugs.webkit.org/show_bug.cgi?id=30385
Summary [Qt] QGLauncher crashes while closing a window
Antonio Gomes
Reported 2009-10-15 05:05:57 PDT
Suppose the following situation: 1) a QGWV object is create. 2) a custom QWebPage-devivated class is create and set as QGWBV's page. QGraphicsWebView* webView = new QGraphicsWebView; WebPage* page = new WebPage; webView->setPage(page); NOTE: "webView" is not parent of "page". 3) submit a load. page->mainFrame()->setHtml("<some/html/here>"); If one tries to delete the "webView" object during the load, it is deleted successfuly (its 'pageClient' reference is also deleted) *BUT* the object "page" itself is not deleted since it is *not* a children of "webView". Ongoing painting actions can still try to access (the now invalid) pageClient pointer right after QGWV deletion. see both attached backtraces...
Attachments
bt1 of the crash (11.61 KB, text/plain)
2009-10-15 05:06 PDT, Antonio Gomes
no flags
bt2 of the crash (11.62 KB, text/plain)
2009-10-15 05:07 PDT, Antonio Gomes
no flags
patch 0.1 + autotests (5.34 KB, patch)
2009-10-15 05:10 PDT, Antonio Gomes
no flags
landed in r49634 - patch 0.2 + autotests (5.66 KB, patch)
2009-10-15 07:12 PDT, Antonio Gomes
no flags
Antonio Gomes
Comment 1 2009-10-15 05:06:55 PDT
Created attachment 41218 [details] bt1 of the crash
Antonio Gomes
Comment 2 2009-10-15 05:07:30 PDT
Created attachment 41219 [details] bt2 of the crash
Antonio Gomes
Comment 3 2009-10-15 05:10:15 PDT
Created attachment 41220 [details] patch 0.1 + autotests
Antonio Gomes
Comment 4 2009-10-15 05:15:42 PDT
err ... many typos. in > Suppose the following situation: > > 1) a QGWV object is create. > 2) a custom QWebPage-devivated class is create and set as QGWBV's page. read: 1) a QGWV object is created. 2) a custom QWebPage-derivated class is create and set as QGWV's page.
Holger Freyther
Comment 5 2009-10-15 06:28:40 PDT
I would be happy with a less fragile test. loadFinished must be guranteed to fire... we should wait for it otherwise we end up in the QSKIP (this platform is too low) mess.
Antonio Gomes
Comment 6 2009-10-15 07:12:07 PDT
Created attachment 41224 [details] landed in r49634 - patch 0.2 + autotests using waitForSignal instead of QTRY_COMPARE, per zecke's suggestion.
Tor Arne Vestbø
Comment 7 2009-10-15 09:59:37 PDT
Comment on attachment 41224 [details] landed in r49634 - patch 0.2 + autotests Looks good, a few comments to fix when you land: > public: > - WebPage(QWidget* parent = 0) : QWebPage(parent) > + WebPage(QObject* parent = 0) : QWebPage(parent) > { Leave out in this patch, but rs on doing it in a followup. > + > +// Task 160192 Cut this > +/** > + * Starts an event loop that runs until the given signal is received. > + Optionally the event loop And add star here ;)
Antonio Gomes
Comment 8 2009-10-15 10:14:29 PDT
thx tor. landed in r49634
Antonio Gomes
Comment 9 2009-10-15 10:16:52 PDT
Comment on attachment 41224 [details] landed in r49634 - patch 0.2 + autotests clearing r+ flag since patch has landed.
Note You need to log in before you can comment on or make changes to this bug.