Able to reproduce the issue on windows 7, Linux Ubuntu 14.04 and Mac 10.11.4.Able see the increasing of memory with each command document.getElementsByTagName("IFRAME")[0].src="http://online-go.com" in console.

This is non regression issue as it is observed from M30 builds.Marking it as Untriaged to get it addressed.

Thanks,

According my tests this may not be completely iframe-specific. On one of our Chrome setups (heavily modified by various settings and flags) I am able to see a similar memory explosion by merely hitting ENTER in the address bar several times, if an affected site is loaded. On another machine with a plain vanilla Chrome, the issue is only reproducible by the above iframe example. So the bug may be somewhere in the handling of outer document contexts (in a generic non-js sense, I don't know Chrome internals). And as I mentioned the leak got much worse between v49 and v50, so we needed to downgrade to v49 and disable updates for the time being (in a production environment with a Chrome-based app).

One more thing: the issue also appears by simply navigating. For example, after loading the iframe only once (steps 1-4 above), issuing 'document.getElementsByTagName("IFRAME")[0].width=900' to ease navigation, then repeatedly clicking on the top links: Puzzles - Chat - Tournaments - Ladder. This changes the url and unloads the document each time, yet memory usage keeps growing.

Actually, this navigation sequence may reproduce the issue even without iframe. Just load the site in a tab, then click the links as above. I saw a memory increase from the normal 60MB to 360MB after about 40 steps, which settled around 300MB after a few minutes (presumably an eventual gc). Not sure if this iframe-less version reproduces on all machines, but on our vanilla Chrome mentioned above the memory usage remained high even after manually typing "about:blank" into the address bar - just shrinked to 180MB. This time, however, task manager also showed high "javascript memory" usage, which was only released after entering a completely different url. (EDIT: this is in contrast of the original iframe example, where not even loading a different url releases the memory)

Moving this nonessential bug to the next milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The browser cannot browse (in an iframe) since longer sessions will always crash. As mentioned we had to downgrade and stop using recent versions as they went from a crash or two per day to a crash or two per hour. I don't see how such a fundamental defect could ever leave beta stage. Having it auto-postponed is just... Incredible.

This issue has been moved once and is lower than Pri-1. Removing the milestone.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

A couple of comments mention this regressing in M50, so the Oilpan team should take a look at this first.

Around version 55 this improved a little. The leak(s) are still there, but not as bad as in 50 (but still worse than in 49). And it got harder to reproduce it, the above steps may not be enough.

Any update on this? This is very similar to  issue 686741  and  529941 . 

Our customers using our web application on their Intranet are finding that the application consumes over 200mb after a couple of iframe navigation's (growing from 30mb) and that Chrome either becomes slow and unresponsive or crashes with a memory error. This is urgent for us and we are approaching the point when we need to start advising users to use IE11, Safari or Edge instead (we are talking about thousands of users). However a lot of these sites have IT policies where Chrome is the default browser and so they are faced with trying to resolve this issue.

Per comment by pfeldman on  issue 686741  comment #7,
https://bugs.chromium.org/p/chromium/issues/detail?id=686741#c7
any leak problem with developer tools open should be handled separately.

This is because developer console or something grabs the references to the
obsolete iframe content and prevents them from garbage-collected, IIUC.

I tried the reproduction of the original issue (reloading iframe repeatedly),
but I could not reproduce it with reloading automatically (proof-of-concept
code attached, but reload URL is left out as blank - so as not to spam
online-go.com etc.).  The tab started ~230MB on my Linux box and stayed
around same after 250 reloads.

Can someone having this problem, show some reproduction cases *without*
needing developer console to be open?

Deleted: auto-reload.html 810 bytes

auto-reload.html 810 bytes View Download

The original problem occurred (and still occurs) without developer console. The repro code was just simplified to the minimum that was sufficient around V50.

As I mentioned earlier, the leak is still there, slightly improved in V55/56, then slightly worsened in V57. But it is harder to reproduce now (with a simplified code), there are probably some other hidden conditions that must met. It does matter what the framed document does, since some pages quickly go up by gigabytes, while others don't crash even after a day. Reloading is also not always necessary, some pages also explode if simply left in an iframe (dom manipulation is a potential problemsource candidate).

In our production environment we wrote an extension that closes/reopens tabs to release memory, it runs hourly to prevent crashes - which would still occur otherwise. :(

I experimented with this a bit more (in V57). I can reproduce the issue outside of our app/extension, but so far only by using a non-public page, so the repro is not directly usable. Still I learned a few things.

First, it seems necessary now that the framed document and the containing parent window be on the same domain (this is one reason the original repro doesn't work anymore).

Second, the whole issue is shaped a bit differently now. Rather than the act of reloading being the source of the problem (on every moderately complex page), it is now most observable with pages that are already loose when loaded directly (memory hungry, either because of an unrelated Chrome leak or page code leaks). Such pages can still be used in a window/tab, since simply navigating/reloading regularly releases memory and prevents them from growing too big. But in an iframe, this release does not happen - on certain conditions, one of which is same domain as above.

Keishi-san, could you follow this up?

So far I haven't been able to repro the issue and there isn't enough information to work on.

Could you send us a V8 heap snapshot using devtools? After the memory is at an unreasonable level, open dev tools and take a heap snapshot, and please attach the .heapsnapshot file to this bug. We might be able to tell who is retaining the iframe contents.

Also, just to confirm. You're initial post was on Windows, but are you still using Windows? Are you using Chrome's task manager to confirm memory usage or the OS's?

 Issue 686741  has been merged into this issue.

As  issue 707544 , which is also a memory leak issue, was fixed in
canary/dev/beta (M58-M59), so it may be worth trying compare M57 and
M58/M59 if that changes anything.

Yes I still test on windows, same setups as earlier (currently V57), and mainly use chrome's task manager. I'm not sure if  issue 707544  is relevant, it is similar but states it was ok in V56, while the iframe-related problems are present since V50 or earlier. But if there is a known leak in V57, that falsifies all my current testing so maybe I should really wait for V58.

I'm reluctant to post dumps since private urls seem to pop up even in a heap snapshot. It would be better to find a public site to reproduce with, or create a simplified repro. I'm experimenting with an outer document with an iframe that reloads in 2m intervals (to leave time for the inner page to consume). This should prevent continuous memory increase because of the reload, yet it makes the most problematic site grow from 70mb to 700 in a few hours. (Chrome's task manager shows normal "javascript memory" usage even when "memory" is already 700mb. Wiping out the whole outer page with about:blank empties the heap but the tab still consumes 500mb.) When I replace the inner site with a dummy page that does some random things, it MAY still reproduce the issue, but it grows much slower so I cannot be sure (from 50-70mb to 200mb overnight, and keeps reaching new peaks). I also found some public site candidates for repro which grow fast, but there "javascript memory" is also high so it may be different problem ( issue 707544 ?). Will try again when V58 arrived (or should I post my current tests regardless?)

Sorry I have been busy with other bugs. M58 should be starting to roll out now. Also if you could be send me the tests I'd be happy to see what's going on. 700MB sounds like something is going wrong.

Any update on when this will be fixed?

I think I figured it out. This is a complex case with 2 or 3 issues involved.

First, I could finally test V58 on all our machines, and found no improvement. (Not even the small improvement I hoped for because of the dom-related fixes - in fact Chrome just got a bit more memory hungry again.)

OTOH, in my simplified test I found an undesirable interaction between the outer and the inner page. This shown how tricky things are now: since in an iframe, a broken inner document MAY attach some of its allocations/contexts to the outer frame (via top.xxx or similar - this was probably the origin of the perceived same-domain requirement for a certain page), which is hard to distinguish from a valid repro. So each page need to be tested several ways (to rule out such outer frame pollutions):

  1. in same-domain iframe  /  2. in cross-domain iframe  /  3. in child window  /  4. in Firefox

OC such pollutions are unlikely to be Chrome-specific, and are a problem in the page itself. This, however, only affected a single page of us, and the majority of the problem (as of V58) lies elsewhere. 

The real leak needs that image display to be disabled in the browser. Then basically any site with lots of images reproduce it (origo.hu for example). In an iframe with a timed reload, or maybe even when loaded directly in a window/tab and hitting reload a few hundred times (after which going to about:blank leaves an empty page consuming hundreds of megabytes). I think even the original repro works still (visibility and active/inactive tab etc may make a difference). I'm not sure if all this is exactly the same as the originally reported iframe issue though.

I agree with your assessment.

For the last issue, we found out that when image loading is disabled, we leak everything!! This turned out to be an old bug  crbug.com/327574  but we will work on a fix.

V59 has arrived to one of our machines, but this version still seems to have the leak (59.0.3071.86).

V60 (60.0.3112.90): the leak is still present.

V61 (61.0.3163.100): the leak seems to be gone.

Thanks for the update!

Despite Comment 27 claiming this issue is fixed, I am seeing it in Version 63.0.3239.84 (Official Build) (64-bit) on macOS Sierra.

See the following example:

https://www.teamstats.net/leak-test.html

4 iframes loading a page that just hosts an image. The iframe src is cleared and then the same page reloaded in the frame every 4 seconds. Watch the memory usage increase.

alex, did you see comment 13? can you confirm that you are seeing the leak *without* devtools open?

I'm experiencing what I think is the same issue. I'm runing Version 63.0.3239.132 (Official Build) (64-bit, windows).

Changing src of the iframe multiple times causes the memory to go up. Profiler indicates that loaded documents and dom nodes stay in memory. Without the devtools opened, the memory goes up and eventually the tab crashes.

Please let me know if you'd like me to provide you with any logs. Thanks.

I'm running Version 64.0.3282.140 (Official Build) (64-bit) and the issue is also visible in my client's application. Within an hour of intensive work it's easy to reach 2GB of RAM usage. It's better than it used to, when with just over 1GB of RAM usage the application was not usable, still it influences the performance.