Bug 54000 - [Qt] Crash on application exit after constructing and destroying a QWebView twice
Summary: [Qt] Crash on application exit after constructing and destroying a QWebView t...
Alias: None
Product: WebKit
Classification: Unclassified
Component: Platform (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P1 Normal
Assignee: Alexis Menard (darktears)
Keywords: Qt, QtTriaged
Depends on:
Reported: 2011-02-08 07:10 PST by Kari Salminen
Modified: 2011-02-14 10:52 PST (History)
4 users (show)

See Also:

Test case for the bug (535 bytes, application/octet-stream)
2011-02-08 07:10 PST, Kari Salminen
no flags Details
Test case that builds (436 bytes, text/plain)
2011-02-09 09:47 PST, Benjamin Poulain
no flags Details
patch (1.29 KB, patch)
2011-02-10 13:26 PST, qi
benjamin: review-
Details | Formatted Diff | Diff
Patch with test case (3.20 KB, patch)
2011-02-14 06:06 PST, Alexis Menard (darktears)
kling: review-
Details | Formatted Diff | Diff
Patch v2 with comments taken into accounts... (3.19 KB, patch)
2011-02-14 06:19 PST, Alexis Menard (darktears)
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Kari Salminen 2011-02-08 07:10:16 PST
Created attachment 81632 [details]
Test case for the bug

How to reproduce the crash (Tested on Qt 4.7.0/Windows XP/MSVC9/Qt Creator 2.0.1):
 - Create a QApplication
 - Loop this twice:
  - Create a QWindow and and a QWebView
  - Set the QWebView as the QWindow's central widget
  - Load an URL (e.g. http://www.google.com/) to the QWebView and show it
  - Execute the QApplication
  - User interaction: Close the window by clicking on the X
 - Exit the program
 - Voila! Crash (Not always, but sometimes).

I've included a webtest.zip containing a webtest.pro and main.cpp
that contains the test case. The test case does not crash every time
on my computer though, only sometimes (I don't think my computer's hardware
e.g. memory, is faulty because the computer is usually very stable).

Also I noticed that on second showing of the Google page not all
looked the same (If there was moving graphics there on the first
run, the second run all was static i.e. not moving).

The real use case behind this bug is using a relogin system in our
commercial software that creates the main window completely from
scratch when logging out and relogging in (We don't shut down the
application in between logging out and relogging in).

--- Stack trace from Qt Creator 2.0.1 with MSVC debugger: ---

Exception at 0x0, code: 0xc0000005: read access violation at: 0x0, flags=0x0

Level	Function	File	Line	Address
0	GetModuleFileNameA	kernel32	0	0x0	
1	WebCore::SharedTimerQt::~SharedTimerQt	SharedTimerQt.cpp	74	0x109ec8f1	
2	WebCore::SharedTimerQt::`scalar deleting destructor'	QtWebKitd4	0	0x109ecdcf	
3	WebCore::SharedTimerQt::destroy	SharedTimerQt.cpp	78	0x109ec94a	
4	WebCore::SharedTimerQt::qt_metacall	SharedTimerQt.moc	74	0x109ecc88	
5	QMetaObject::metacall	qmetaobject.cpp	238	0x671ca551	
6	QMetaObject::activate	qobject.cpp	3272	0x671e1dc6	
7	QCoreApplication::aboutToQuit	moc_qcoreapplication.cpp	131	0x67263049	
8	QCoreApplication::exec	qcoreapplication.cpp	1015	0x671c103d	
9	QApplication::exec	qapplication.cpp	3673	0x6506e458	
10	main	main.cpp	17	0x401189	
11	WinMain	qtmain_win.cpp	131	0x4023ca	
12	__tmainCRTStartup	crtexe.c	578	0x4018a8	
13	WinMainCRTStartup	crtexe.c	403	0x40160f	
14	RegisterWaitForInputIdle	kernel32	0	0x7c816fe7	


    if (m_timer.isActive())
} // <------ debugger points here at level 1 (Points to assembly code on level 0)

According to https://svn.webkit.org/wiki/QtWebKitRelease20 QtWebKit that comes
with Qt 4.7.0, which I'm using, was branches off WebKit trunk from SVN r56441
("AppleWebKit/533.3") and thus I chose 528+ as the version number.

I chose to report this here instead than in the Qt's bug tracker because of
Henry Haverinen's comment on 25/May/10 12:24 PM at
http://bugreports.qt.nokia.com/browse/QTWEBKIT-189 hoping that this is
the correct place for this bug.
Comment 1 Benjamin Poulain 2011-02-09 09:47:42 PST
Created attachment 81824 [details]
Test case that builds
Comment 2 Benjamin Poulain 2011-02-09 09:50:30 PST
Crash: I set as P1.

I can reproduce everytime with trunk on Linux.

#0  0x0000000000000000 in ?? ()
#1  0x00007ffff703522c in WebCore::SharedTimerQt::~SharedTimerQt() () from /home/ikipou/dev/webkit/qtwebkit/WebKitBuild/Release/lib/libQtWebKit.so.4
#2  0x00007ffff7035289 in WebCore::SharedTimerQt::~SharedTimerQt() () from /home/ikipou/dev/webkit/qtwebkit/WebKitBuild/Release/lib/libQtWebKit.so.4
#3  0x00007ffff7035147 in WebCore::SharedTimerQt::qt_metacall(QMetaObject::Call, int, void**) () from /home/ikipou/dev/webkit/qtwebkit/WebKitBuild/Release/lib/libQtWebKit.so.4
#4  0x00007ffff514bfaf in QMetaObject::activate(QObject*, QMetaObject const*, int, void**) () from /home/ikipou/dev/qt-oslo-staging-2_release_64/lib/libQtCore.so.4
#5  0x00007ffff513a5a3 in QCoreApplication::exec() () from /home/ikipou/dev/qt-oslo-staging-2_release_64/lib/libQtCore.so.4
#6  0x0000000000400e18 in main ()
Comment 3 qi 2011-02-10 13:26:25 PST
Created attachment 82035 [details]

Comment 4 Benjamin Poulain 2011-02-10 13:28:46 PST
Comment on attachment 82035 [details]

This really needs an autotest.
Comment 5 Alexis Menard (darktears) 2011-02-14 06:06:32 PST
Created attachment 82310 [details]
Patch with test case
Comment 6 WebKit Review Bot 2011-02-14 06:09:02 PST
Attachment 82310 [details] did not pass style-queue:

Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCor..." exit_code: 1

Source/WebKit/qt/tests/qwebpage/tst_qwebpage.cpp:2824:  This { should be at the end of the previous line  [whitespace/braces] [4]
Total errors found: 1 in 4 files

If any of these errors are false positives, please file a bug against check-webkit-style.
Comment 7 Andreas Kling 2011-02-14 06:11:25 PST
Comment on attachment 82310 [details]
Patch with test case

View in context: https://bugs.webkit.org/attachment.cgi?id=82310&action=review

> Source/WebKit/qt/tests/qwebpage/tst_qwebpage.cpp:2823
> +    for (int i = 0; i < 2; ++i)

Coding style, { on this line.

> Source/WebKit/qt/tests/qwebpage/tst_qwebpage.cpp:2831
> +        webView->load(QUrl(QLatin1String("http://www.google.com/")));
> +        mainWindow.show();
> +        connect(webView, SIGNAL(loadFinished(bool)), &mainWindow, SLOT(close()));
> +        QApplication::instance()->exec();

We can't rely on external websites in our autotests.
Comment 8 Alexis Menard (darktears) 2011-02-14 06:19:45 PST
Created attachment 82311 [details]
Patch v2 with comments taken into accounts...
Comment 9 Antonio Gomes 2011-02-14 06:25:13 PST
Comment on attachment 82311 [details]
Patch v2 with comments taken into accounts...

View in context: https://bugs.webkit.org/attachment.cgi?id=82311&action=review


> Source/WebCore/ChangeLog:8
> +        Check the value is valid before use it.

Nit: "Check IF.."
Comment 10 WebKit Commit Bot 2011-02-14 10:50:50 PST
The commit-queue encountered the following flaky tests while processing attachment 82311 [details]:

fast/history/history-subframe-with-name.html bug 51039 (author: mihaip@chromium.org)
The commit-queue is continuing to process your patch.
Comment 11 WebKit Commit Bot 2011-02-14 10:52:23 PST
Comment on attachment 82311 [details]
Patch v2 with comments taken into accounts...

Clearing flags on attachment: 82311

Committed r78490: <http://trac.webkit.org/changeset/78490>
Comment 12 WebKit Commit Bot 2011-02-14 10:52:28 PST
All reviewed patches have been landed.  Closing bug.