Bug 44691 - [Qt] QtTestBrowser crashed after loading 60 pages
Summary: [Qt] QtTestBrowser crashed after loading 60 pages
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: S60 Hardware S60 3rd edition
: P1 Blocker
Assignee: Viatcheslav Ostapenko
URL:
Keywords: Qt, QtTriaged
Depends on: 49012
Blocks:
  Show dependency treegraph
 
Reported: 2010-08-26 09:02 PDT by Alexandra Santos
Modified: 2010-11-16 12:06 PST (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alexandra Santos 2010-08-26 09:02:55 PDT
While running stability test on QtTestBrowser using QtWebkit 2.1, the browser crashed after loading 60 live websites. This, when running on Symbian 4 platform. Please refer to the attached crash log for analysis.
Comment 1 Suresh Voruganti 2010-08-27 10:50:36 PDT
Proposing this to top issue for QtWebkit 2.1, so adding this bug 39121
Comment 2 Simon Hausmann 2010-08-30 08:38:50 PDT
The binary crash log can be found in the internal Qt issue QT-3827
Comment 3 Alexandra Santos 2010-09-23 13:04:41 PDT
After retesting this issue using a build from the Oslo codecamp folder, Only 38 live sites could be loaded before a crash was observed. This, when using the Symbian 4,QtWebkit 2.1 + QtTestBrowser.
Comment 4 Jay Tucker 2010-09-27 08:24:03 PDT
Assigning to myself.
Comment 5 Nancy Piedra 2010-10-10 06:17:29 PDT
On N8 we can now load 80 live websites and 585 (all) canned web sites.  This is leading me to believe the problem could be in XHR as Simon suggested.  I imagine all XHRs would fail on canned sites since those URLs would not have been canned.

The following two errors seem like they may be related:

https://bugs.webkit.org/show_bug.cgi?id=46746 
https://bugs.webkit.org/show_bug.cgi?id=37191
Comment 6 Nancy Piedra 2010-10-15 08:05:04 PDT
After applying the Qt fix for QVGImagePool we can now load 189 live websites.

We are still looking at XHR issues.  There are patches being proposed to 2.1
Comment 7 Viatcheslav Ostapenko 2010-10-15 12:00:02 PDT
One of the crashes I've got several times looks very similar to this (on Qt 4.7.0 release): https://bugs.webkit.org/show_bug.cgi?id=44691

I'll rerun test with patch applied to verify that it helps.
Comment 8 Viatcheslav Ostapenko 2010-10-15 12:03:55 PDT
(In reply to comment #7)
> One of the crashes I've got several times looks very similar to this (on Qt 4.7.0 release): https://bugs.webkit.org/show_bug.cgi?id=44691
> 
> I'll rerun test with patch applied to verify that it helps.

Sorry, I mean this: http://bugreports.qt.nokia.com/browse/QTBUG-12285
Comment 9 Robert Hogan 2010-10-20 12:20:12 PDT
(In reply to comment #2)
> The binary crash log can be found in the internal Qt issue QT-3827

How can I test this? Can we get a copy of the backtrace here?
Comment 10 Viatcheslav Ostapenko 2010-10-25 08:34:01 PDT
After running stability tests on N8 with released Qt 4.7.0 :

There is 3 problems in Qt (already solved, but not included into release), that affect QtTestBrowser stability:
1. QVgImagePool:reclaimSpace() problem
http://qt.gitorious.org/+qt-developers/qt/releases/commit/771cfe6f172820a1a370255cb74e066913408a6f
2. Problem in with abort of http post:
http://bugreports.qt.nokia.com/browse/QTBUG-12285
3. Bug in gif conversion: 
http://qt.gitorious.org/qt/staging/commit/4d974ff0a748b22e668a4cb7ef38101122c85b3b

After patching QT 4.7.0 release QtTestBrowser is able to load about 180-190 websites. Running memory monitor in parallel showed, that QtTestBrowser eats all memory (96Mb by default).
Increase of process available memory to 256Mb allowed to load about 230-240 websites before crash. After loading about 220 websites phone became slow and unresponsive (got into paging? ).

I've caught also several crashes in WebCore::IconDatabase::syncThreadMainLoop. There are several bug reports open with similar crash stack. Trying to figure out, if this is fixed and what patch applies.
Comment 11 Nancy Piedra 2010-10-29 08:41:58 PDT
When running QtTestBrowser with Qt 4.7 stable branch we have better memory consumption (and there for don't see the out-of-memory problems).  Also, Qt 4.7 stable we don't seem to see the network crashes.  However, networking stops working after around 280-290 sites.

So, current status is that we can load about 280-290 sites when using a more recent version of Qt.
Comment 12 Nancy Piedra 2010-11-03 02:27:15 PDT
The following two patches will improve memory consumption on Symbian.  These patches are required to achieve the 300 site stability metric.

https://bugs.webkit.org/show_bug.cgi?id=48730

https://bugs.webkit.org/show_bug.cgi?id=48767
Comment 13 Suresh Voruganti 2010-11-03 08:08:02 PDT
(In reply to comment #12)
> The following two patches will improve memory consumption on Symbian.  These patches are required to achieve the 300 site stability metric.
> https://bugs.webkit.org/show_bug.cgi?id=48730
> https://bugs.webkit.org/show_bug.cgi?id=48767

I have marked the above 2 errors as blocking 39121, so that these fixes are cherry picked to Qtwebkit 2.1
Comment 14 Nancy Piedra 2010-11-06 02:47:45 PDT
In order to load all websites we will need this fix also:

https://bugs.webkit.org/show_bug.cgi?id=49012
Comment 15 Suresh Voruganti 2010-11-08 06:33:54 PST
(In reply to comment #14)
> In order to load all websites we will need this fix also:
> https://bugs.webkit.org/show_bug.cgi?id=49012

Added the dependency for 39121 master bug for Qtwebkit 2.1, so the fix should be cherry picked to Qtwebkit 2.1
Comment 16 Suresh Voruganti 2010-11-16 12:06:35 PST
This issue is no longer reproducible as originally described. After testing on N8 device, QtTestHarness successfully completed the stability test  loading 437 live websites. This test was run overnight using WLAN. 
NOTE: A second run during the day (when WLAN is normally really busy) showed that QtTestHarness could load 398 live websites, ending the test with a "Page not Found Message" due to underlying networking issues . No crash observed.

So closing the error as WorksForMe.