New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 772 link

Starred by 10 users

Issue metadata

Status: Verified
Owner:
Last visit > 30 days ago
Closed: Oct 2008
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

CPU hits 100% in Browser process and locks up browser

Reported by zunderh...@gmail.com, Sep 3 2008

Issue description

Product Version      : 0.2.149.27
URLs (if applicable) : www.gametrailers.com
Other browsers tested:
Add OK or FAIL after other browsers where you have tested this issue:
Safari 3:
Firefox 3:
IE 7:

What steps will reproduce the problem?
1. Open task manager
2. Play an embedded HD video (gametrailers)
3. While the video is playing scroll the page up and down

What is the expected result?
The page should scroll and normal browser operation should continue

What happens instead?
CPU utlitization of "Browser" process hits 100% and the browser will hang 
for approximately 10 seconds, or until a warning pops up saying the tab is 
not responding.

Please provide any additional information below. Attach a screenshot if 
possible.

I'm using a single core CPU (athlon64 2800)
 
 
Labels: -Area-Unknown Area-Plugins
This looks like it might be a duplicate of  Issue 1087  and  Issue 93  (scrolling with a 
video Plugin pegs the CPU, poor Flash performance, etc.)

From the looks of this issue, scrolling seems to be problematic with non-Flash video 
players as well.


Labels: flash v-153.1
Status: Untriaged
I don't see a 100% spike and lock down of Chrome but definitely Chrome is using more 
CPU when scrolling compared to other browsers. 

This might be a dupe of  issue 93  or  issue 1087 . Leaving it open till they are fixed.
This only seems to happen on single core machines, where the browser process takes up
100% CPU starving the Flash plugin process (which is running at below normal
priority). Pushing up the priority of the Flash plugin process stops this from happening.
Labels: -area-plugins Area-WebKit Plugins
Deprecate Area-Plugins label in favor of Area-WebKit and a separate Plugins 
label (reducing number of Area- labels).

Comment 5 by ananta@chromium.org, Sep 30 2008

Status: Started

Comment 6 by ananta@chromium.org, Sep 30 2008

This can also be reproduced with the following URL.
http://finance.google.com/finance?q=INDEXDJX:.DJI%20INDEXNASDAQ:.IXIC%20INDEXSP:
Move around the chart with the left mouse button pressed down. Then click outside
on the browser window.


Status: Fixed
Fixed in revision 2740

This fixes http://code.google.com/p/chromium/issues/detail?id=772,
which was an issue with the browser UI thread entering a tight loop
at times. The thread inputs of the browser UI thread and the plugin thread
are attached due to the parent child relationship between the windows.

As a result at times the MsgWaitForMultipleObjectsEx API returns the
fact that there are messages in the queue (mouse messages). The subsequent
peek fails to return any messages causing us to enter a loop for a while.
This also happens when the plugin has capture and just before it releases capture, 
some mousemoves end up in the browser ui thread causing a tight loop.

The fix is to check if there are mouse messages in the queue by invoking
GetQueueStatus and attempting to peek them out with PM_NOREMOVE. If this
fails we call WaitMessage to block until the next message.

The other fix is to return true from ProcessNextWindowsMessage if PeekMessage returns 
false and there were sent messages in the queue, as
this is as expected. This will ensure that we go back up and peek again
instead of calling MsgWaitForMultipleObjectsEx again.

Comment 8 by jam@chromium.org, Oct 1 2008

 issue 387  looks like a dup of this..
Labels: v-154.1
Status: Verified
Looks like much better now. I don't see the tab hanging while playing the above 
trailers (in the original bug report) and scrolling the tab at time.

-Venkat.
Project Member

Comment 10 by bugdroid1@chromium.org, Oct 12 2012

Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 11 by bugdroid1@chromium.org, Mar 11 2013

Labels: -Area-WebKit Cr-Content
Project Member

Comment 12 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink

Sign in to add a comment