My favorites | Sign in
Project Home Downloads Wiki Issues Code Search
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 113983: Memory usage increasing infinitely on every tab refresh
92 people starred this issue and may be notified of changes. Back to list
Reported by piotr.halaczkiewicz, Feb 13, 2012
Chrome Version       : 18.0.1025.11
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) : any
Other browsers tested:
  Firefox 9.0.1: OK
  IE 9: OK

What steps will reproduce the problem?
1. Open browser.
2. Open chrome://memory
2. Open new tab and navigate to any site (the more complex it is, the easier it will be to notice the issue). Note memory usage for the tab in chrome://memory.
3. Repeatedly refresh the site, waiting for page to fully load after each refresh. Note increasing memory usage after each refresh.

What is the expected result?
Memory usage for a tab should depend on the displayed content. If additional memory is required to hold information about browsing history or cache for the tab, it should be reasonable in size, preferably with some limits, either user-defined or depending on available system memory. If system is running short on memory or limits are reached, any information that could be recreated, should be freed.

What happens instead?
Chrome uses all available memory. During a normal browsing activity it is not uncommon for a single tab to hit 1 GB range memory usage.
To free memory, user has to close the tab and reopen the page in new tab.

See also:


UserAgentString: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/535.19 (KHTML, like Gecko) Chrome/18.0.1025.11 Safari/535.19

Feb 13, 2012
#1 piotr.halaczkiewicz
Forgot to add:

It is good if application can make use of available memory, but this behavior in Chrome ultimately leads to system slowdown and/or browser/tabs crashing.
Feb 26, 2012
I'm not sure if I'm experiencing the exact same problem, but I'm definitely seeing a memory leak.  I've got a site using HTML5 appcache and IndexedDB that reloads every hour via javascript on a kiosk and it will invariably grow in memory usage until it crashes.
Feb 28, 2012
I have the same problem too, every time I reload the browser, the memory of that tab increased.
Feb 29, 2012
dlong500: We've identified and fixed some resource leaks in IndexedDB. If possible, please try Chrome Canary builds (tomorrow's should have a fix for in it). The fixes are specific to IDB though, so unlikely to be relevant to the original report.
Apr 9, 2012
Same here on 19.0.1084.15-r130829 on Debian. This page, for example, eats additionally about 9MB on each refresh. Another page eats abut 28 MB.
Apr 10, 2012
(No comment was entered for this change.)
Labels: Stability-Memory
Apr 23, 2012
all I need to do is leave a few tabs open and walk away for a bit.. when I come back im at 96% of all my memory used (even though I have nothing else open on the pc) and need to close chrome tabs which now have in order upwards of 1 gb each thru task manager to release it.  then repeat a little while later.

I don't even need to refresh. 

20.0.1105.2 dev-m
May 8, 2012
Having this same problem on Opensuse with chrome Version 19.0.1084.41 beta
tabs just constantly eat memory. ive had chrome open for 10 minutes now, and i have 6 tabs that have already surpassed 100 or 200mb EACH. If i leave it open for more than an hour, or use one tab more than others the memory usage will keep increasing steadily, surpassing 2gb for a SINGLE TAB. Chrome never seems to release the memory its used, and just continues to eat it. It gets so bad to the point where my system hardlocks as it literally runs out of memory. I have not had a problem like this in nearly half a decade. 
Jun 6, 2012
Same on Ubuntu 11.04 64 bit with Version 20.0.1105.0 dev.

We have a web page showing the status of a system that refresh every minute. The memory usage reaches 1.7GB after 5 hours. The page is all plain static HTML and no image or javascript. The header has

<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="-1">
<meta http-equiv="Cache-Control" content="no-cache">
<meta http-equiv="refresh" content="60" >

Please note the memory usage in other browsers (Firefox, Opera) is fine.
Jun 8, 2012
speedogoo, can you share that page? 
Oct 29, 2012
This happens on all tabs on my Google Chrome version: 23.0.1271.52 beta-m. Ref

Refreshing tab never releases memory, only closing tab and re-opening does. I have several sites running ~1GB of memory because of this. Sigh. Really problematic if you have lots of pinned tabs, as re-opening them is pain.
Oct 29, 2012
It's most painful on pages which has <meta http-equiv="refresh" content="X" />
such as and After two days, and each tab using ~1GB I must restart Chrome, fix it people! It happens on all pages even those which doesn't have refresh meta tag.

(I run several news sites as pinned tabs, and occasionally also refresh all tabs)
Oct 29, 2012
Anantha, Karen--

Have you seen similar bugs on 23? Seems to be a couple of sites we could try to repro in comment #12.

Might be an extension?
Status: Untriaged
Labels: -Area-Undefined Area-Internals
Oct 30, 2012
Looks like this issue is happening from M20 onwards and we have similar bugs reported on M23. This issue happens on Linux Ubuntu 12.04 & Mac OS X10.8.2 also.
Oct 30, 2012
Team is in the process of confirming the similar bug reports. They will update the status here.
Nov 2, 2012
I am able to replicate the issue with on both M22 and M23 builds.  I left running over night on both builds. The memory usage increased from ~60MB to ~300MB.  Memory usage also increases if you reload the tab.
Status: Assigned
Nov 2, 2012
jar@ suggested using memory profiler to see what is happening. Trying it out.
Nov 2, 2012
I will try that now.
As requested I am listing the steps that would replicate the issue:
1. Load
2. Open Chrome task manager and monitor memory usage.
3. Reload the tab.

Issue: Memory usage increases with every tab reload.
Nov 2, 2012
Attached is chrome://profiler/ info.
472 KB   View   Download
Nov 2, 2012
+ jamesr@,  rvargas@

Trying the deep memory profiler to see if we get any more data than chrome://profiler for memory (attached in comment#19).
Nov 2, 2012
Able to reproduce this on Win7 - 22.0.1229.96, 23.0.1271.52 & 24.0.1312.0
Please find the attache screen shots.

Steps to repo the issue:

1. Open chrome.
2. Navigate to any site 
3. Navigate to Tools -- Task manager and Check the memory in task manager or chrome://memory
4. Repeatedly refresh the site,waiting for page to fully load after each refresh.Note increasing memory usage after each refresh.
M23 stats.PNG
169 KB   View   Download
Nov 2, 2012
(No comment was entered for this change.)
M22 Stats.PNG
621 KB   View   Download
Nov 2, 2012
Attached is the snapshots of memory profile stats from a Linux box

The tab was hidden during the idle time test. The page does an auto
refresh. We allocate memory when it is refreshed. We GC and free the
memory at regular intervals.  

"Private memory" for the Tab, in Task Manager of Chromium keeps
increasing over a period of time. 

The following are some observations from the data.

1) One of the video Ads, on this page kept on cycling through videos
  (even though the tab is hidden).

2) This page seems to auto refresh even though that tab is hidden.

3) Renderer grew by 150k in 90 mins and grew by 500mb in 3 hrs.

4) Browser and other tabs have been steady.

5) Shockwave plugin's memory varies between 50k to 150k.

6) We had seen lot of JS and security errors in JS console for (happens with FF also).

7) Only 50% of the memory used by renderer is being allocated by
   tcmalloc (with flash enabled)

   Based on the following data, memory used by both tcmalloc and JS is
   Private memory    tcmalloc's virtual address space used
   90mb              47mb
  127mb              64mb 
  135mb              68mb
  205mb              95mb (81mb is committed)
  295mb             120mb (104mb is committed)

jar@ had mentioned JS doesn't use tcmalloc.

TODO (after talking with eroman)
1) Going to another experiment with plugin (shockwave plugin) disabled.
2) Run with UMDH
3) Try the Deep memory profiler

With JS dev tools, renderer crashed for me (thus didn't take heap snap shots of JS).
7.7 KB   View   Download
Nov 2, 2012
Data with plugins disabled (no shockwave).

1) Attached file shows the difference between snapshots from about:profiler
   (memory profiler). Around 54 mins of memory allocation in renderer by tasks.

2) I think, we are leaking around 10mb per refresh.

   The following is the data from Chromium's Task Manager and about:tcmalloc

   Private memory     tcmalloc's virtual address space used
   115mb              59mb (51mb used by application)
   131mb              65mb (57mb used by application)
   140mb              71mb (60mb used by application)
   168mb	      81mb (69mb used by application)
   181mb	      85mb (73mb used by application)
   199mb	      89mb (77mb used by application)
   221mb	      99mb (88mb used by application)
   274mb	     118mb (103mb used by application)

   Memory growth:

   Total memory:   159mb
   tcmalloc:        59mb (52mb used by application)
   non-tcmalloc    100mb

   Per page refresh, on average total memory grows by 10mb.

4) Firefox grew from 133mb to 176 mb (43mb of growth)
   IE grew from      230mb to 1GB    (770mb of growth)

3.0 KB   View   Download
Nov 5, 2012
Launched on both Win7 and Mac osx machines on Friday just to check what happens if they are left idle over the weekend - 23.0.1271.60 (Official Build 164911)

Tab crashed on Win7.

Please find the attached screen shots.

Tab Crash.PNG
531 KB   View   Download
Nov 5, 2012
(No comment was entered for this change.)
Screen Shot 2012-11-05 at 9.52.23 AM.png
135 KB   View   Download
Nov 5, 2012
Deep memory profiler points out

mmap-v8-heap-pagedspace      grows from 31mb to 570MB

nonprofiled-anonymous        grown from 13mb to 98mb

tc-webcore-node-and-doc heap grows from  2mb to 68MB

mmap-v8-heap-coderange       grows from  5mb to 28mb

tc-webcore-script-execute    grows from  4mb to 22MB
tc-webcore-style-createsheet grows from .2mb to 21MB

Nov 5, 2012
The following document has detailed data from deep memory profiler. (Is it possible that there is a bug in the website's JS code that it is hanging on to JS data?)

Renderer crashes because it runs out of memory.

Could there be an JS array like the following that keeps growing and doesn't delete data it.

                  var _gaq = _gaq || [];
		  _gaq.push(['_setAccount', 'UA-589309-2']);

anantha@: would appreciate if this issue could be reassigned to the right owner.
Status: Available
Nov 5, 2012
assigning to V8 PM to find an owner. Stefano, Please feel free to unassign if this is not V8 issue.
Status: Assigned
Nov 5, 2012
This is reproducible on Mac osx 10.8.2 & Linux/Ubuntu 10.04 - 23.0.1271.60 (Official Build 164911)
347 KB   View   Download
Labels: -OS-Windows OS-All
Nov 5, 2012
(No comment was entered for this change.)
Nov 6, 2012
This should atleast be fixed by M24, if not by next M23 update.
Labels: Mstone-23 ReleaseBlock-Stable
Nov 6, 2012
24 seems more likely at this point since m23 is on stable now.
Labels: -Mstone-23 Mstone-24
Nov 6, 2012
But is the patch something we can take on 23 in case there's an update?

I'm not sure what fixed it, but if it's simple enough it would be nice to update the Stable channel before 24 (since that's at least 6 week away).
Nov 8, 2012
I use a script that has indexDB functions and this is catastrophic, its totally unusable. I had to disable the indexDB portions to just use it without having to open a new tab every 20 seconds (literally).

This has also made me discover that it is impossible to downgrade chrome :(
Last version I had that didn't slow to crawl was v21.
Nov 9, 2012
Short update: I started investigating this and can reproduce the problem. Even a low-memory notification doesn't bring down memory usage. Also the fragmentation of the spaces looks fine. One suspicious thing is that the map-space kept growing in size with every reload. The following shows the progress for about 10-ish page reloads.

[19923] Map space,          used:    260 KB, available:    875 KB, committed:   1135 KB
[19923] Map space,          used:   1052 KB, available:   1091 KB, committed:   2143 KB
[19923] Map space,          used:   2069 KB, available:   2090 KB, committed:   4159 KB
[19923] Map space,          used:   2211 KB, available:   1947 KB, committed:   4159 KB
[19923] Map space,          used:   3479 KB, available:   3702 KB, committed:   7182 KB
[19923] Map space,          used:   3265 KB, available:   3916 KB, committed:   7182 KB
[19923] Map space,          used:   4599 KB, available:   3590 KB, committed:   8190 KB
[19923] Map space,          used:   6756 KB, available:   3449 KB, committed:  10205 KB
[19923] Map space,          used:   8605 KB, available:   6638 KB, committed:  15244 KB
[19923] Map space,          used:   8578 KB, available:   6665 KB, committed:  15244 KB
[19923] Map space,          used:  10628 KB, available:   6631 KB, committed:  17259 KB
[19923] Map space,          used:   9642 KB, available:   7616 KB, committed:  17259 KB
[19923] Map space,          used:  11944 KB, available:   7330 KB, committed:  19275 KB
[19923] Map space,          used:  13405 KB, available:   6877 KB, committed:  20283 KB
[19923] Map space,          used:  12400 KB, available:   7882 KB, committed:  20283 KB
[19923] Map space,          used:  14234 KB, available:   8064 KB, committed:  22298 KB
[19923] Map space,          used:  13742 KB, available:   8555 KB, committed:  22298 KB
[19923] Map space,          used:  16558 KB, available:   7755 KB, committed:  24314 KB
[19923] Map space,          used:  16429 KB, available:  10908 KB, committed:  27337 KB
[19923] Map space,          used:  14063 KB, available:  13273 KB, committed:  27337 KB

I also looked at the distribution of live objects on the heap and it looks as if a lot of closures, maps and descriptor arrays are kept alive. The following is some statistics after the 10-ish page reloads. I just pasted the lines (unit is bytes) that jumped out on me and I also pasted the heap layout after the last GC to get some relation to the overall size.

size_of_FIXED_ARRAY_TYPE: 36796536
size_of_JS_FUNCTION_TYPE: 13772088
count_of_FIXED_ARRAY_TYPE: 189584
count_of_JS_FUNCTION_TYPE: 191279

[19923] Memory allocator,   used: 196624 KB, available: 1302512 KB
[19923] New space,          used:      0 KB, available:  16384 KB, committed:  32768 KB
[19923] Old pointers,       used:  72259 KB, available:  38925 KB, committed: 111364 KB
[19923] Old data space,     used:   4830 KB, available:   4431 KB, committed:   9261 KB
[19923] Code space,         used:   4924 KB, available:   4038 KB, committed:   8964 KB
[19923] Map space,          used:  14063 KB, available:  13273 KB, committed:  27337 KB
[19923] Cell space,         used:   1122 KB, available:   3036 KB, committed:   4159 KB
[19923] Large object space, used:      0 KB, available: 1301471 KB, committed:      0 KB
[19923] All spaces,         used:  97200 KB, available:  80088 KB, committed: 193854 KB

This made me fire up the cross-context separation verification, because the above statistics just smell like a cross-context leak. And after about the third reload I could find a cross-context leak in our generated code. I need to investigate further to find out whether it's real leak or the tool is lying to me. I'll keep digging.

# Fatal error in ../../v8/src/, line 304
# CHECK_EQ(current_native_context_, native_context) failed
#   Expected: 0x8ed50f69401
#   Found: 0x351ff9804101
Nov 11, 2012
using chrome 22.0.1211.0 on raspberrypi

I am also impacted by this on a site that programmatically replaces some div's content every minute with new information coming in from XHR (containing some div, span, and 2 images, one svg which is constant, and another one that can be jpeg, animated gif or png).
the images are stored on the server.

I have verified that my JS doesn't leak with the timeline memory tool.

the application crashes in a few hours.
Nov 16, 2012
Notice that stable Chrome has this bug too, I downgraded to stable while ago.

Interesting note is that the bug "spreads" to other tabs *after* visiting at least once. I've resorted to not reading Haaretz until it is fixed.
Nov 16, 2012
Just get a chromium derivative like Iron or some such that has no auto update and install v21. That way you avoid this bug until it is fixed rather then not going to website you actually want to use.
Nov 23, 2012
I finally got around to investigating this further and found out that each reload adds another context that is weakly reachable but kept alive by another global handle through some listener. The "Path to object" section below shows the only strong path to the context and also includes a backtrace of when the persistent handle was created. The following dump is the state after two reloads.

Found CTX in strong global handle: 0x1ae69e696dd9 <FixedArray[68]>
Found CTX in weak global handles:  0x1ae69e696dd9 <FixedArray[68]>
Found CTX in weak global handles:  0x282cf2804101 <FixedArray[68]>
        ====        Path to object       ====    
                0/4: 0x2119a035d2a1 <JS Function>
                1/4: 0x1f2a5133f441 <FixedArray[8]>
                2/4: 0x1f2a513f23a9 <JS Function>
                3/4: 0x282cf2804101 <FixedArray[68]>
        Found in node 0x7fffe87a62d8
        Backtrace for 0x7fffe87a62d8 (13):
Found CTX in weak global handles:  0x19dda9e3d439 <FixedArray[68]>
        ====        Path to object       ====    
                0/4: 0x16db1b9ef381 <JS Function>
                1/4: 0x14b861642571 <FixedArray[8]>
                2/4: 0x268275bbd2f9 <JS Function>
                3/4: 0x19dda9e3d439 <FixedArray[68]>
        Found in node 0x7fffe8a246b0
        Backtrace for 0x7fffe8a246b0 (13):
That is a total of 2 weakly reachable CTXs

I also dumped the source for the two closures that are part of the strong path keeping the context alive, to see where the listener installed in JavaScript. The following is a dump of the source for the two functions in minimized form. It can easily be run through a beautifier to make it readable.

Source for first closure on path (i.e. 0x16db1b9ef381):

Source for second closure on path (i.e. 0x268275bbd2f9):
function(a,b,c){function e(){if(a._pg){return a._p_g&&}a._pg=true;var c=b.getElementById("_pgc"),e=b.createElement("script");e.type="text/javascript";e.async=true;e.src=c?c.src.replace("embedded","printitgreen"):"//";d(e)}function d(a){(b.getElementsByTagName("head")[0]||b.getElementsByTagName("body")[0]).appendChild(a)}var f,g=b.createElement("script");"_pgl";if(!b.getElementById({d(g);if(a.matchMedia){f=a.matchMedia("print");f.addListener(function(a){if(a.matches){e()}})}return a.addEventListener?a.addEventListener(c,e,false):a.attachEvent&&a.attachEvent("on"+c,e)}}

At this point I am pretty certain it is not a V8 issue, but an issue with the listeners not being cleared during context disposal on the Webkit bindings side. Jochen, Marja, can you help me to triage this further?
Nov 23, 2012
Jochen, Marja, can you help me to triage this further?
Nov 26, 2012
Simpler repro case:

function getOrientationValue (mediaQueryList) {
portraitOrientationCheck = window.matchMedia("(orientation: portrait)");

For measuring this:
1. Start chrome with --user-data-dir=/tmp/somethingunique --js-flags="--expose_gc"
2. Load this page on a tab, reload N times
3. Do window.gc(); window.gc(); via developer tools
4. Check the tab memory in chrome://memory

mstarzinger@: this should be enough to get all the garbage collected, right?
Nov 26, 2012
The above repro triggers the same accumulation of strongly reachable contexts and the reachability pattern is similar to the original page.

Yes, calling window.gc() twice should fire weak callbacks and get rid of the disposed contexts. An alternative to step 3 would be to hit the "Trash-Can" button in the developer tools timeline tab. This will fire a low-memory notification and cause the most aggressive GC that V8 can provide. Even that one does not reclaim the contexts ATM.
Nov 26, 2012
Afaics this is a WebKit bug (a circular reference: ~Document has code to clean up listeners in MediaQueryMatcher, but ~Document never happens because MediaQueryMatcher references Document).

We (jochen@ and I) have an understanding how to fix this. I'll follow up with getting the fix through...
Nov 26, 2012
(No comment was entered for this change.)
Status: Started
Nov 26, 2012
(No comment was entered for this change.)
Labels: -wkbug103242 WebKit-ID-103242
Nov 26, 2012
Labels: -WebKit-ID-103242 WebKit-ID-103242-RESOLVED WebKit-Rev-135709
Nov 26, 2012
Requesting merge of to M24
Labels: Merge-Requested
Nov 26, 2012
Please merge it in 1312 branch.
Labels: -Merge-Requested Merge-Approved
Nov 26, 2012
committed at
Status: Fixed
Labels: -Merge-Approved Merge-Merged-1312
Nov 28, 2012
Final question: How do I know when this commit/update is pushed to stable?
Nov 28, 2012
Hmm, when Chrome 24 reaches stable (it's now in beta), afaics.
Nov 28, 2012
Which would mean that Chrome beta has it already? (more than worth switching if so)
Nov 28, 2012
yes, 24.0.1312.25 beta build has the fix.
Nov 28, 2012
I'd need a version compiled for raspbian ;-)
Dec 2, 2012
Am I correct in assuming that this fix is also in Canary or is it only in the beta branch?

My issues with IndexedDB and page refreshes are still not fixed in 25.0.1346.0.  Someone mentioned that there were some bug fixes with resource leaks in IndexedDB, but that was 8 months ago and my problems haven't gone away.  They may be unrelated to this specific issue, so I might need to start a new ticket.
Dec 2, 2012
The fix is also in Canary.

Please file another bug for the indexdb issue.
Dec 23, 2012
24.0.1312.45 beta-m

issue still badly existing...

To reproduce I just open a google drive spreadsheet and refresh the page n times, the memory consumtion drastically goes up each time
Jan 2, 2013
I'm able to reproduce this too using the instructions in c#59. If docs uses web workers, I wonder whether this is .
Status: Assigned
Jan 2, 2013
Since this is an issue from M18, I'm removing the blocker label for M24. The fix will be merged whenever its ready.
Labels: -ReleaseBlock-Stable
Jan 2, 2013
An update to Google internal bug 7911677 indicates that MutationObservers were causing resource leaks until just recently. See .

Jan 3, 2013
Just did a test per comment 59 and comment 60, reloading a Google spreadsheet many times. Tested on my own Linux Chromium build at r175018 and WebKit r138690. I changed the source in src/v8/src/extensions/ to "native function gc2()" (because Docs defines its own window.gc function) and ran Chromium with the command line arguments --js-flags="--expose-gc --trace-gc". I also added logging to MutationObserver.cpp, WebWorkerClientImpl.cpp, and WebSharedWorkerImpl.cpp in WebKit, which shows that Google Docs isn't using workers or mutation observers.

I can see an increase in memory usage for the renderer process according to Chrome's task manager during the first few (4-5) reloads of the spreadsheet. Afterward, however, the memory usage levels off, and some reloads cause it to drop significantly. At the points where memory consumption is high, calling  window.gc2() repeatedly from the developer tools causes the memory usage to drop, though not all the way back to its original level. Leaving the window alone for a while (~30 seconds), however, surprisingly causes the memory usage to drop significantly -- nearly all the way back to its original level. I suspect that this is a consequence of V8's "idle notification" being called.

In sum, with Docs, I do not currently see unbounded memory growth. I did not test with Chrome 24 so don't know whether a leak might have been fixed since then.

Jan 6, 2013
Reassigning to kbr@ who seems to have be working on this.

Note: this bug seems to be about a different issue than originally. The original issue related to MediaQueryList was fixed, and has not regressed. Comments >= 59 are talking about a separate issue.
Jan 7, 2013
I'm not actively working on this and am actively working on other issues so am unassigning myself. Moving it back to Unconfirmed state per my analysis above -- I can not reproduce unbounded memory growth. Needs an owner (and a reliable test case) or needs to be closed.

Status: Unconfirmed
Owner: ---
Jan 8, 2013
(No comment was entered for this change.)
Labels: nomedia
Jan 17, 2013
Haaretz I believe got fixed. I'm now using 24.0.1312.52 m (the stable)... But now I'm seeing other tabs such as New York Times (using ) increasing infinitely.

It's now clocking 660MB for (Global) NYT front page, after several days of usage.
Jan 17, 2013
@jari.pennanen: can you try to come up with a series of steps which demonstrate the memory leak more quickly? For example, reloading the page, clicking forward and backward to many articles, etc.?

Jan 17, 2013
I have noticed that being on for a long period causes chrome to bloat a bit (it does to all browsers). I have saved several gigs of ram simply by restarting chrome (with the continue where left off option).

I suspect that whatever memory leak is causing it is a different bug then 113983.

My first guess would be repeatedly loading ads but I have them blocked and yet still experience the bloat.

Anyways, repeatedly refreshing does not increase the memory used on it on my browser. (v24).
Jan 18, 2013
@kbr, I never navigate away from the front page. It is pinned, and I periodically refresh the page, now it is 900MB.

Other suspects are Economist, which is now 400MB.

My pinned news tabs usage is only refreshing (and opening links to new tab if I'm interested on navigating).
Jan 18, 2013
Third suspect, which also is 450MB.

So try to reproduce those by refreshing multiple times.
Jan 19, 2013
Proof of my sanity, screenshot.

Started the chrome with --user-data-dir="G:\Temp\" to ensure no plugins or crap was turned on. Refresshed constantly for period of 5 minutes, got 200MB of usage already. Notice: It requires a lot of refreshing, like every 5 seconds to get there.

Windows 7 64bit.
221 KB   View   Download
Jan 21, 2013
I tried with , and, but I can't (yet) reproduce. Otoh, I was forcing the garbage collection quite aggressively, and testing on Linux, tip-of-tree Chrome.

jari.pennanen@: Does the issue still occur if you force garbage collection? To do so: hamburger menu -> Tools -> Developer Tools -> select the "Timeline" tab -> click the trash can button on the bottom left (tooltip: "Collect garbage".)
Jan 21, 2013
I'm using Version 26.0.1386.0 dev and can reproduce it using

It starts with 90M and grows....
Every time I reload it wastes a "peak", goes down a little, but remains higher than previous amount, like +50M 

Garbage collection does not affect how much memory is wasted

Jan 22, 2013
@ma..., Nope. Manual garbage collection does not help, it drops a few megabytes sometimes (as one would expect) but it does not release most memory from previous refreshes.

In my computer the memory increases at the beginning around ~1-2 MB per refresh, then after many refreshes (totalling now 150MB for the NYT tab) it starts to increase more on each refresh.

This is actual problem at least on my way of using the browser, the NYT page was already at 500MB as I closed to try reproduce with clean profile moments ago. 

It happens even when FlashBlock and Adblock are enabled (as well as with clean profile without plugins).
Jan 22, 2013
Sorry for spamming, but one could write a unit test that refreshes some websites mentioned and run it in the farm, I suppose Google has something like it? I think it would be a good test even after the bug in NYT page gets fixed, it could be harnessed for future testing. I know it's a bit catch-all test, but I think it would be valuable to have such data between builds.
Jan 22, 2013
I posted c#59 - now Version 25.0.1364.36 beta-m

I confirm the NYT does not overload memory. Please be careful in the test-cases that refreshing n times quickly actually overgrowes the memory, but after a while (refresh the memory tab) the memory goes back to normal.

Regarding to my original test case on google drive, this is exactly the same.

In my personal javascript application the problem disappears as well.

My problem is solved. Thanks.
Jan 23, 2013
@sebastie, No it does not come back. That's what I meant that in my normal usage (when browser has been running several days) the NYT tab just never releases memory until I close the tab. Same with other tabs mentioned, it does not help to wait at all.
Jan 31, 2013
Changing the milestone to M26 for now. Please change it to the appropriate milestone.
Labels: -Mstone-24 Mstone-26 MovedFrom-24
Feb 15, 2013
I have traced my case of memory leak to the Google Publisher Toolbar extension (

I have a munin graphs webpage without javascript, with a meta refresh to itself, and a bunch of graphs. I have the page hosted in a domain outside the domains configured in the Google Publisher Toolbar, I even tried with a clean profile not synced to google and not logged in anything. In the Developer Tools memory timeline you could see Document Count increasing by 1 and DOM Node Count by some very high number on every page refresh. According to chrome task manager it was memory allocated to javascript, that's why I said that the munin page does not have any javascript, only a meta refresh and images.

The memory was never released, I even clicked in garbage collect, but didn't work.

Feb 16, 2013
I agree with #80, this seems related to certain extensions. It's very easy to repeat:

1) Install Google Dictionary extension ( Of the extensions I have installed, only this one will cause the memory leak.

2) Go to (any page will work) and reload the page repeatedly.

3) Watch the memory usage increase in developer tools > timeline.

Feb 18, 2013
This is indeed reproducible with the Google Dictionary extension, like described in comment 81.
Feb 20, 2013
This is likely due to the use of deprecated extension APIs, i.e chrome.extension.onRequest and chrome.tabs.sendRequest. See:
Feb 21, 2013
There is to check wich extensions/apps use them?

I use a lot of extensions, and the Extensions Manage Page is doesn't help to really manage them. It doesn't let us check wich permissions our apps use, or doesn't let we filter by who is enabled... well, it doesn't help.

So how we could check every extension we had installed to prevent these leaks ?

Feb 25, 2013
I've created two separate bugs for the extensions mentioned here, since they will have to be fixed individually. See:

Feb 25, 2013
Since multiple extensions are causing it under identical conditions it is entirely possible that a singular issue is causing it.
Feb 25, 2013
If it is indeed deprecated extension APIs that are causing this memory usage increase, perhaps the Chrome / Web Store team can search through all the extensions and notify the various developers of those extensions and let them know of better APIs to use.

Then, perhaps after a month or two, you could list them below extensions that don't have that problem if they still use those deprecated APIs as an additional incentive to get them to update their extension to use the new APIs that don't have this issue.

Then, another month or two later, de-list them if they're causing this memory usage problem.
Feb 25, 2013
On a possible related note, a page that grows in memory over time is the Google Drive background page.

On a machine with 4GB of RAM that I use and leave on all the time, I've actually had Chrome using over 2GB.  At least a third of that was the Google Drive background page.
Feb 25, 2013
Issue was tested. Chrome with no tabs uses 189689K memory. Opened up youtube page and Chrome now uses 360738K memory. After a couple refreshes of the youtube page, memory usage remained constant at 360000 range. No noticeable increase in memory usage. 

The process was repeated for facebook and the results were similar. This issue could not be replicated. This report should indicate 
Feb 25, 2013
For me it was an internal munin page and the adsense Google Publisher Toolbar extension.

I have searched over the internet for a public sample: download it with the images, change the meta refresh to a shorter time like 3 seconds for a better effect and let the browser refresh it while monitoring the memory usage. Watch the Developer Tools memory timeline you will see Document Count increasing by 1 and DOM Node Count by some very high number on every page refresh.
Feb 26, 2013
it could be reproduced on DevChannel.

1) install/enable Google Dictionary (by Google) extension.
2) open
3) reload N times. Each reload takes ~1.2Mb
Feb 26, 2013
Version 26.0.1410.12 dev
Feb 28, 2013
After a little digging it turns out that the Google Publisher Toolbar extension leak is actually due to
Mar 6, 2013
Maybe there is something fundamental that I'm missing, but regardless of any memory leak issue, why is it that reloading a page doesn't actually release memory?  If I have a tab that starts off using about 100MB, then grows to 350MB, and then I reload the page, it will stay at 350MB usage (both on stable and Canary).  In fact, if I type in another page on the same domain, it STILL stays at 350MB.  Only if I go to a different domain will the tab actually release memory and start over from "scratch".  This seems counter-intuitive.  There should at lease be a flag or switch to enable destroying and recreating a process upon reloading/refreshing a page rather than reusing the existing process (if not being the default behavior).  It would seem that such a behavior would at least effectively work around many of the memory leak issues (even if said memory leaks are largely due to extensions).
Mar 6, 2013
If you crash the tab and then reload then it releases everything, that's my workaround at the moment, but it's, like #94 said, counter-intuitive. I have lots of extensions enabled and seems it's a bit here and there that gets added for each.
Please find some way to stop the leak, regardless of extension.
Mar 7, 2013
#96, unfortunately if you're using Chrome in a kiosk/signage application like I am there is no good way to "crash" a tab and recover programatically.  I've just put in place a test scenario where a page at domain X redirects to a page at domain Y at a specified interval, and the page at domain Y immediately redirects back to the page at domain X.  Since both pages have offline manifests then it should still work in an offline scenario.  We'll see if this ends up being a stable scenario, although it is such a kludge vs just having javascript issue a page reload.
Mar 10, 2013
(No comment was entered for this change.)
Labels: -Area-Internals -Stability-Memory -Mstone-26 Performance-Memory Cr-Internals M-26
Apr 1, 2013
(No comment was entered for this change.)
Labels: -Performance-Memory Stability-Memory
Apr 3, 2013
Bulk edit: Moving non-release blocking bugs to M28.
Labels: -M-26 M-28 MovedFrom-M26
Apr 11, 2013
On the left here it says Resolved nut I'm still getting this issue. (On chrome version 26.0.1410.64 m)

This problem has been happening on many machines for me with chrome. It's more obvious with advert heavy sites. Such as

If you go to the site and refresh there is a 20-40mb jump in memory usage until the browser becomes slow and unusable.

Apr 12, 2013
I am also still experiencing this issue. Typically I notice on sites where I am browsing several pages. Examples: and To resolved I have been using the task manager to kill the page.
Apr 12, 2013
@101 & 102: Does it still happen in incognito mode? If not, it's most likely an extension.
Apr 13, 2013
Wow the problem didn't happen in incgonito so I went the route of enabling one extension at a time and testing a tab out by refreshing a website continuously.

It turns out the 'Google Dictionary' extension was the culprit. When turned off the memory use rarely went above 150mb. When turned on the memory use increased by 40-50mb with each refresh.

I believe it solved my problem. So it was the Google dictionary extension. Can people check if disabling the extension fixes the issue for them also.
Apr 13, 2013
I have over 20 extensions enabled, each one making it add up some.
It should not add when refreshing, regardless.
Apr 13, 2013
@104: Yeah, that one is known to leak memory. I wrote up a specific bug about the dictionary extension a while ago:
Apr 13, 2013
@104: Yes, disabling the 'Google dictionary' solved my problem too.

May 7, 2013
(No comment was entered for this change.)
May 8, 2013
This issue has already been moved once and is lower than Priority 1,therefore removing mstone.
Labels: -M-28 MovedFrom-28
May 18, 2013
Now we have version 26 and this bug still persists. 
Every page reload causes memory leak. 
Forget using chrome for more than 4 tabs. 
Memory problems are reported for more than one year, and seems that Chromium team is ignoring this main problem that causes this browser unusable. 

May 18, 2013
Here's a list of the extensions I have, marked Enabled for those that are active.

4chan X 3.4.3 - Enabled
500px 1.19 - Enabled
Antisocial 0.2.4
Autocomplete = on 1.0
Autofill 5.5
Black Menu 4.0.4
Chrome Notepad 3.7
Chrome to Mobile 1.0.0 - Enabled
Chrome Update Notifier Plus 0.5 - Enabled
CrxMouse 2.5.405.1394 - Enabled
Downloadify 0.1
Feedly Beta 14.0.490 - Enabled
Form Filler
Gallery Viewer 0.6
Godville 1.25
Google Chrome to Phone Extension 2.3.1 - Enabled
Google Docs 0.5 - Enabled
Google Reader Unread Count 12 - Enabled
Hover Zoom 4.18 - Enabled
Keyboard-fu 0.7.1 - Enabled
Magic Actions for YouTube™ 5.8.6 - Enabled
Reddit Enhancement Suite - Enabled
Reditr - Best Reddit Client - Enabled
RPG for Chrome 1.3.8
Scrollbar Anywhere 2.4
Session Buddy 3.2.1 - Enabled
Sidewise Tree Style Tabs 2013.5.8.0 - Enabled
Smooth Gestures 0.17.7
Stylish 1.1 - Enabled
Tab Statistics 1.0.2 - Enabled
Tampermonkey Beta 3.1.3399 - Enabled
Template 1.2.5 - Enabled
TweetDeck 2.8.2 - Enabled
Unfriend Finder 41.997 - Enabled
uSelect iDownload 1.9
Walking in Chrome 2.5
Wet Banana 0.4.1
Write Space 0.60
May 20, 2013
Chrome canary (29.0.1512.0 (1512.0)) with 150 tabs uses all memory without reloading all tabs and then crashes. A few days ago, everything was ok. But now its broken :(
The newest chromium x86_64 mac build is not affected.
73.7 KB   View   Download
Jun 4, 2013
Reproduced on Ubuntu 13.04. Any page, without refreshing is indefinitely increasing memory consumption, even with extensions disabled.
Jun 6, 2013
The problem seems to have lowered in magnitude (if not outright gone away) after I migrated from Mandriva One 2011.0 to Mageia 3.
Jun 11, 2013
Finally find the place....
I've experienced this for a long time as a web developer who needs to reload the same page for hundreds of times every single day. The memory usage will infinitely increase by 5 ~ 35 mb (depending on the complexity of the webpage) up on every refresh, which eventually slow down my whole system.
Please solve this. 

System: LinuxMint 14 && Ubuntu 12.10 && Ubuntu 13.04 (all 64-bits version)
Chrome version: from 23 to current
CPU: i7 740qm
Ram: 2 x DDRII 1333 4G
Jun 12, 2013
I have the same problem.

Chrome version: 27.0.1453.110
OS: Mac OS X 10.8.4
CUP: 2.9 GHz Intel Core i7
Ram: 8 GB 1600 MHz DDR3
Jun 12, 2013
 Issue 126064  has been merged into this issue.
Jun 12, 2013
(No comment was entered for this change.)
Jun 22, 2013
OK I'm having the same issue. I just found out while developing an Angular app. I thought I might have memory leak in my app but since lots of people having same issue, it looks like a bug. I'll further debug my app for memory leak.
Jul 10, 2013
I also experience this bug. Chrome 28.0.1500.71. I have a large number of tabs (usually around 100) distributed across a number of windows.

When I start Chrome it quickly consumes all my CPU and all of my RAM (16GB). Through the task manager I end every process using more than 200,000K(!!!!!). If I reload the pages again I don't see the same memory consumption.

An example of the ridiculous nature of this awful bug is this page: 


By itself in a single process, it uses in excess of 330,000K! That's with Flash Block. After killing the process and restarting it uses 93K.

Please, *PAH-LEASE* Chrome devs, work hard towards fixing this bug. I can reproduce the issue any time, so if you would like me to collect any info for you let me know.

OS: Ubuntu Raring AMD64
CPU: Intel i7 Q840 & 1.87GHz
Jul 29, 2013
 Issue 163101  has been merged into this issue.
Aug 14, 2013
(No comment was entered for this change.)
Blockedon: chromium:270000
Oct 24, 2013
Easiest reproduction of the bug :
 1. open this html.
 2. push the alloc button to allocate some memory
 2. in devtools timeline panel, push trash icon to gc the memory
Expected: memory is freed up
timeline shows that memory is freed up so page is not leaking 
but task manager shows an amount of memory is still reserved, and not released even if page reload, or tab change.
tested in stable chrome incognito mode and chrome canary without any plugin

  <button id="garbage">alloc memory</button>
var button = document.querySelector('#garbage');
button.onclick = function(){
  var i;
  for (i = 0;i<10000000;i++){
Oct 30, 2013
(No comment was entered for this change.)
Labels: Performance-Memory
Nov 11, 2013
I feel that this bug has too many heads to be useful. If I am reading this right, issue 270000 should at least take care of the vast majority of the complaints.

I will go ahead and close this bug as WontFix with the meaning of Invalid (multiple bugs being filed in the same report).

If you have other issues beside the "memory bloats does not go away after a reload" generic issue, please file a new bug so that we can be more effective at triaging them. Thanks in advance.
Status: WontFix
Jan 30, 2014
I am surprised that this is not being fixed. I also have this issue with chrome 32.0.1700.102 m. Come on guys.
Jan 30, 2014
As per comment #129, please file separate bugs with as much specifics as possible. Closing this one.
Labels: Restrict-AddIssueComment-EditIssue
Sign in to add a comment

Powered by Google Project Hosting