Bug 30385 - [Qt] QGLauncher crashes while closing a window
Summary: [Qt] QGLauncher crashes while closing a window
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Qt (show other bugs)
Version: 528+ (Nightly build)
Hardware: PC All
: P2 Normal
Assignee: Antonio Gomes
URL:
Keywords: Qt
Depends on:
Blocks: 30354
  Show dependency treegraph
 
Reported: 2009-10-15 05:05 PDT by Antonio Gomes
Modified: 2009-10-16 06:22 PDT (History)
2 users (show)

See Also:


Attachments
bt1 of the crash (11.61 KB, text/plain)
2009-10-15 05:06 PDT, Antonio Gomes
no flags Details
bt2 of the crash (11.62 KB, text/plain)
2009-10-15 05:07 PDT, Antonio Gomes
no flags Details
patch 0.1 + autotests (5.34 KB, patch)
2009-10-15 05:10 PDT, Antonio Gomes
no flags Details | Formatted Diff | Diff
landed in r49634 - patch 0.2 + autotests (5.66 KB, patch)
2009-10-15 07:12 PDT, Antonio Gomes
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Antonio Gomes 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...
Comment 1 Antonio Gomes 2009-10-15 05:06:55 PDT
Created attachment 41218 [details]
bt1 of the crash
Comment 2 Antonio Gomes 2009-10-15 05:07:30 PDT
Created attachment 41219 [details]
bt2 of the crash
Comment 3 Antonio Gomes 2009-10-15 05:10:15 PDT
Created attachment 41220 [details]
patch 0.1 + autotests
Comment 4 Antonio Gomes 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.
Comment 5 Holger Freyther 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.
Comment 6 Antonio Gomes 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.
Comment 7 Tor Arne Vestbø 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 ;)
Comment 8 Antonio Gomes 2009-10-15 10:14:29 PDT
thx tor.

landed in r49634
Comment 9 Antonio Gomes 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.