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

Issue 177659 link

Starred by 10 users

Issue metadata

Status: Fixed
Owner:
Last visit > 30 days ago
Closed: Mar 2013
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment

100% continuos cpu usage and memory going up (even while doing nothing)

Reported by vie...@yubo.be, Feb 22 2013

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/537.22 (KHTML, like Gecko) Chrome/25.0.1364.99 Safari/537.22

Steps to reproduce the problem:
Seems random/Cannot determine exact steps

What is the expected behavior?
Do not get stuck on an infinite loop allocating more and more memory and using 100% cpu.

What went wrong?
After browsing reddit and wikipedia (only one/two tabs open) the cpu usage by the browser process jumped to 100% and the memory usage started going up, nonstop until it reached 1Gb in less than 20-30s. 

This problem only started after the auto-update to 25 that got pushed yesterday.

After the second ocurrence of the problem I deleted my profile (rm -fr ~/Library/Application\ Support/Google/Chrome/Default) but today the problem happened again.

Crashed report ID: 

How much crashed? Just one tab

Is it a problem with a plugin? No 

Did this work before? Yes 24

Chrome version: 25.0.1364.99  Channel: stable
OS Version: OS X 10.8.2
 
Screen Shot 2013-02-22 at 1.01.25 PM (2).png
446 KB View Download
Screen Shot 2013-02-22 at 1.00.05 PM (2).png
447 KB View Download
Screen Shot 2013-02-22 at 12.59.07 PM (2).png
446 KB View Download
Screen Shot 2013-02-22 at 1.00.21 PM (2).png
446 KB View Download

Comment 1 by meh...@chromium.org, Feb 22 2013

Labels: Stability-Performance
Bummer that it's random. If you see it happening, do you have enough time to grab a trace before it crashes? Or is it hung at that point?

http://www.chromium.org/developers/how-tos/trace-event-profiling-tool/recording-tracing-runs

I notice the AdBlock extension running. If you disable that, does that have any effect? Perhaps we have a bad interaction there.

Also, when you say, "just one tab crashes," do you mean that only that tab crashes (you get the sad tab logo for that tab, but Chrome is still running), or only one tab is open and Chrome disappears completely?

Comment 3 by vie...@yubo.be, Feb 23 2013

Hello, thanks for responding so quickly.

Yes if it happens again I have enough time to grab a trace following the instructions in the link you provided.

Regarding adblock: It's hard to say because I don't know how to reproduce the problem. After posting this bug report, even with adblock enabled, it did not happen even once. Before posting, in less than an hour it happened twice.

None of the tabs crashes. Even while consuming 100% cpu I can still scroll, etc. I opened a new tab and closed the reddit one without problems (even tough the Google Chrome process continued using 100% cpu until I killed it). As the memory usage grows (without ever stopping) everyting starts to get really sluggish and eventually I cannot do nothing...
I see. Yeah, a trace would be great to show where all of that CPU time is going. And if you could disable AdBlock for a couple of days, I'd like to know if you still see the problem.

Comment 5 by vie...@yubo.be, Feb 24 2013

Hello,
It happened again. I attached the trace. I will disable adblock (only extension I have) and see if it happens again.
trace-2013-2-24.zip
1.9 MB Download
Labels: Feature-Sync
50,000 calls to RestartWaiting on the sync thread. Do any sync people know anything about this?
That sounds like a bug in the sync scheduler.  Could you post the contents of about:sync when this happens?  That might have some information that could help narrow down the source of the problem.

Comment 8 by vie...@yubo.be, Feb 26 2013

Suspecting the problem was related to sync I was dumb enough to go clean the data on the server (via Google Dashboard) and re-adding the account so now I am not sure if I can have it happen again. But if it does what should I post specifically? Dump Sync Events? Dump Sync Data? Dump client server traffic?

Thanks for all your help.
Huh.  I forgot that we have so many dump options these days.

The "Dump sync events to text" button will include more than enough information for us.  If you could copy everything from the "Status" header up to (but not including) the "Log", that would be great.  You probably don't want to include the "Log" section, since it could contain private data.

Alternatively, you could look at the "About" tab, select all (Ctrl+A) and copy/paste it into the bug.  That contains almost as much information, and it's in a slightly more readable format.  Either option would work for me.  
FYI, we are seeing similar issues with the latest chrome using the supergrep interface (https://github.com/etsy/supergrep)

Comment 11 by vie...@yubo.be, Feb 27 2013

Hello,

The problem happened again and I followed your instructions and clicked "Dump sync events to text". The file is attached. I was going to also copy the About tab but this time Chrome crashed (I think it used all the memory). The OS generated a crash dump that I also attached hoping that it might be useful.
sync_dump.txt
11.7 KB View Download
osx_crashreport.txt
75.4 KB View Download
Thanks!  Those files were a big help.

<jargon>
I think the bug is related to the way we're throttling search engines.  On startup, we'll try to commit some search engine changes.  That request will fail because search engines are currently disabled server-side ( issue 134857 ).

The SyncScheduler doesn't handle this case very well.  It will try again to commit search engines, but this will be blocked by the per-datatype throttling check in SyncScheduler::DecideOnJob().  It will save the job and attempt to retry it.  Unfortunately, this code path is shared by many other scenarios, and, in those scenarios, it makes sense to not change the scheduled wake up time.  In this scenario, we've already reached that wake up time, so we're going to try again immediately.

It should be possible to break out of this cycle by sending a nudge for a different data type to the scheduler.  That will change the result of SyncScheduler::DecideOnJob(), allowing the job to proceed, succeed, and forget about the pending nudge for search engines.  (That's actually kind of a bug,  issue 155296 , but it works in our favor here.)  This is probably the way that most users have managed to avoid this issue.

vieira's case is special.  He's disabled many of the most active data types (sessions, typed URLs), so it's likely no additional nudges will come in to break the scheduler out of this loop.
</jargon>

If this theory is corerct, vieira should be able to escape from this infinite loop scenario by making a change to a data type that he does sync, ie. preferences.  (I would have suggested bookmarks, but according to the dump, that type is not in a very healthy state right now.  That may be a separate bug.)  

To prevent this from happening in the first place, vieira could manually disable search engine sync.

Comment 13 by vie...@yubo.be, Feb 27 2013

Hello, thanks for looking into it!

I can live without search engine sync but I can't find an option to disable it. In the chrome://settings > Advanced Sync Settings there is no checkbox for Search Engines and I can't find anything related to search engine sync in chrome://flags. How can I manually disable search engine sync?
Sorry, forgot about that.  I think it's grouped under the "Settings" checkbox.

You can use about:sync to double check that you've successfully disabled it.
Project Member

Comment 15 by bugdroid1@chromium.org, Mar 1 2013

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=185528

------------------------------------------------------------------------
r185528 | tim@chromium.org | 2013-03-01T11:16:52.316713Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/sync/engine/sync_scheduler_impl.cc?r1=185528&r2=185527&pathrev=185528
   M http://src.chromium.org/viewvc/chrome/trunk/src/sync/engine/sync_scheduler_whitebox_unittest.cc?r1=185528&r2=185527&pathrev=185528

sync: Drop fully datatype throttled sync jobs rather than saving them.

This avoids a bug where we loop infinitely with calls to RestartWaiting
with a zero WaitInterval length, which happens in part because we don't 
honour ThrottledDatatypeTracker unthrottle times and rely on seperate
exponential backoff treatment.

BUG= 177659 


Review URL: https://chromiumcodereview.appspot.com/12386012
------------------------------------------------------------------------
Labels: Mstone-26 Merge-Requested
Could someone please confirm if the fix helped with the memory consumption? thanks!
I believe I'm suffering from the same issue, but my I noticed the original bug said only one tab crashed.  I'm on windows, and my entire chrome crashes.
Today's canary (27.0.1429.0) looks ok to me. I have used multiple tabs, and notice no immediate issues with the browser. 
Labels: -Merge-Requested Merge-Approved

Comment 20 by Deleted ...@, Mar 5 2013

I was having the same issue and disabling the search engine sync seems to have fixed it.
Project Member

Comment 21 by bugdroid1@chromium.org, Mar 5 2013

Labels: -Merge-Approved merge-merged-1410
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=186215

------------------------------------------------------------------------
r186215 | tim@chromium.org | 2013-03-05T18:59:28.896949Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1410/src/sync/engine/sync_scheduler_impl.cc?r1=186215&r2=186214&pathrev=186215
   M http://src.chromium.org/viewvc/chrome/branches/1410/src/sync/engine/sync_scheduler_whitebox_unittest.cc?r1=186215&r2=186214&pathrev=186215

Merge 185528
> sync: Drop fully datatype throttled sync jobs rather than saving them.
> 
> This avoids a bug where we loop infinitely with calls to RestartWaiting
> with a zero WaitInterval length, which happens in part because we don't 
> honour ThrottledDatatypeTracker unthrottle times and rely on seperate
> exponential backoff treatment.
> 
> BUG= 177659 
> 
> 
> Review URL: https://chromiumcodereview.appspot.com/12386012

TBR=tim@chromium.org
Review URL: https://codereview.chromium.org/12464005
------------------------------------------------------------------------
Project Member

Comment 22 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Stability-Performance -Feature-Sync -Mstone-26 Cr-Services-Sync M-26 Performance
Project Member

Comment 23 by bugdroid1@chromium.org, Mar 12 2013

Labels: merge-merged-1364
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=187611

------------------------------------------------------------------------
r187611 | tim@chromium.org | 2013-03-12T17:55:15.735537Z

Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/1364/src/sync/engine/sync_scheduler_impl.cc?r1=187611&r2=187610&pathrev=187611
   M http://src.chromium.org/viewvc/chrome/branches/1364/src/sync/engine/sync_scheduler_whitebox_unittest.cc?r1=187611&r2=187610&pathrev=187611

Merge 185528 "sync: Drop fully datatype throttled sync jobs rath..."

> sync: Drop fully datatype throttled sync jobs rather than saving them.
> 
> This avoids a bug where we loop infinitely with calls to RestartWaiting
> with a zero WaitInterval length, which happens in part because we don't 
> honour ThrottledDatatypeTracker unthrottle times and rely on seperate
> exponential backoff treatment.
> 
> BUG= 177659 
> 
> 
> Review URL: https://chromiumcodereview.appspot.com/12386012

TBR=tim@chromium.org
Review URL: https://codereview.chromium.org/12781007
------------------------------------------------------------------------
Owner: tim@chromium.org
Status: Started

Comment 25 by tim@chromium.org, Mar 18 2013

Status: Fixed
Closing as this seems to be resolved.  

Bug 181262 tracks this bug on m25. 
 Bug 155296  (and more generally,  bug 175024 ) tracks  what is captured by the remaining TODO in sync_scheduler_impl.cc.
Labels: hasTestcase

Sign in to add a comment