Bug 13183 - REGRESSION: 100% CPU (but no beachball) when loading Gmail
Summary: REGRESSION: 100% CPU (but no beachball) when loading Gmail
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Page Loading (show other bugs)
Version: 523.x (Safari 3)
Hardware: Macintosh PowerPC OS X 10.4
: P1 Normal
Assignee: Nobody
URL: http://mail.google.com/mail/
Keywords: Regression
Depends on:
Blocks:
 
Reported: 2007-03-24 15:09 PDT by Alex Kan
Modified: 2007-03-25 17:56 PDT (History)
3 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex Kan 2007-03-24 15:09:11 PDT
On my G4 450 MHz Cube, WebKit CPU usage goes to 100% and stays there once the page is almost loaded (the black "Loading..." on the left side has already disappeared and only the red-on-white "Loading..." box on the right remains). Page loading then appears to make no forward progress. Sharking WebKit at this point shows a lot of time spent in WebCore::TimerBase::sharedTimerFired(), which seems to consist mostly of CoreFoundation timer adding and invalidation.

This appears to have started sometime between r20387 and r20419, from my testing with the builds on nightly.webkit.org, and doesn't happen on my MBP with the same builds. On my Cube, it also happens sporadically with other webpages, but not with the same reproducibility of Gmail (i.e. I can get pages to load eventually if I stop and reload). I don't have another PPC machine here to reproduce this with, unfortunately.
Comment 1 mitz 2007-03-24 15:24:01 PDT
I've seen this happen a few times (thought it was a server side problem).

Based on the revision range where it regressed, there is a slim chance that this bug has the same root cause as bug 13179.
Comment 2 David Kilzer (:ddkilzer) 2007-03-24 15:40:35 PDT
I see a slight pause with 100% CPU using my PB G4, too, in a local debug build of WebKit r20470 versus shipping Safari.  (It's slightly less noticeable on my Quad G5 desktop. :)

Comment 3 mitz 2007-03-24 15:47:04 PDT
It's not 100% reproducible for me, but I failed to reproduce it even a single time after applying the patch from bug 13179 locally.
Comment 4 mitz 2007-03-25 02:25:22 PDT
Alex, please check if this is fixed in the r20486 (or later) nightly. Thanks!
Comment 5 David Kilzer (:ddkilzer) 2007-03-25 09:00:33 PDT
(In reply to comment #4)
> Alex, please check if this is fixed in the r20486 (or later) nightly. Thanks!

This still occurs for me with a local debug build of WebKit r20488 with Safari 2.0.4 (419.3) on Mac OS X 10.4.9 (8P135).
Comment 6 David Kilzer (:ddkilzer) 2007-03-25 10:03:39 PDT
(In reply to comment #5)
> (In reply to comment #4)
> > Alex, please check if this is fixed in the r20486 (or later) nightly. Thanks!
> 
> This still occurs for me with a local debug build of WebKit r20488 with Safari
> 2.0.4 (419.3) on Mac OS X 10.4.9 (8P135).

I never saw a hang; only slower login times with a debug build.  When I ran a release build (a WebKit nightly build), it performed the same as shipping Safari.

Comment 7 Adam Roben (:aroben) 2007-03-25 13:54:28 PDT
(In reply to comment #5)
> (In reply to comment #4)
> > Alex, please check if this is fixed in the r20486 (or later) nightly. Thanks!
> 
> This still occurs for me with a local debug build of WebKit r20488 with Safari
> 2.0.4 (419.3) on Mac OS X 10.4.9 (8P135).
> 

   For what it's worth, this problem went away for me when I built r20487.
Comment 8 Alex Kan 2007-03-25 17:05:27 PDT
(In reply to comment #4)
> Alex, please check if this is fixed in the r20486 (or later) nightly. Thanks!

I am no longer seeing this in the r20487 nightly.
Comment 9 David Kilzer (:ddkilzer) 2007-03-25 17:56:36 PDT
Closing as RESOLVED/FIXED per Comment #8 and Comment #7.