We meant memory LEAK.
Also, it seems the memory does climb even on non-WebGL pages (just not as fast).

Tested this issue on Debian Rodete with chrome Stable #64.0.3282.140 & Beta #65.0.3325.51 and observed 2 different behaviors.

Observations:
1. For Stable M64, observed that browser memory usage is rising for each refresh.
3. For Beta M65, observed browser is freeing some memory and after few seconds memory usage is rising again for each refresh.

Attaching the screen-cast for reference.

danielgjorwell@ Could you confirm the behavior shown in M65 is the correct behavior of this issue?

Thank You...

Deleted: 811220-M65.mp4 2.5 MB

	811220-M65.mp4 2.5 MB View Download

Deleted: 811220-M64.mp4 7.5 MB

	811220-M64.mp4 7.5 MB View Download

I don't have M65 but I can confirm that in Chrome Canary v66 the memory is released after about 5-10 seconds. It still grows but only by about 5% per refresh (95% of memory recovered over time).

Browser build discrepancy:
It is very interesting that 10 refreshes in Chrome v64 grows the memory usage from 400 to 800mb (recovering to 740 after 10 seconds).

Chrome Canary v66 increases memory usage from 270Mb to 400Mb but recovered to 280Mb after 10 seconds.

If Chrome of later version will work as the Canary build, then I don't think we have an issue anymore. Provided it works the same for mobile devices of course.

Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

I have the same experience with OSX. When profiling the memory heap in devtools after a couple of tab-"refresh" everything from earlier "refreshes" is still in memory, all js-objects and even the document DOM tree. A refresh should release all those, as it do in Canary. Are we bound to wait for M66 for the fix, or could this be fixed with a patch? This issue becomes problematic with large projects and auto-reload-tools like BrowserSync.

GPU resources owned by WebGL contexts are eagerly released when navigating away from a web page or reloading it. This report seems to be about the renderer-side CPU memory consumption and not specifically about WebGL.

I reloaded the given URL many times in Chrome 66.0.3346.0 (Official Build) canary (64-bit) on macOS and seem to see a slow growth in the memory usage of the tab's renderer process, but not the GPU or browser processes.

Would need a bisect and confirmation of existence of a memory leak in earlier builds of Chromium to make progress.

I'm working on Google Interland project and each page-refresh raises the memory footprint twice as much. Chrome 66 is fine for me too, problems occurred with M64. Seems more like a v8/context/cache problem. Maybe the webgl context is just a coinsident, since memory leaks is more likely detected when lots of data like ArrayBuffers. In the screenshot attached I have refreshed the page 3 times. Each time a new instance of every class is created and a new DOM tree. What's interesting is that when I inspect those objects, I see a lot of "bound_this in native_bind()". On some object it the only reference in the tree. So it's maybe those bind()-calls that prevent the page from being freed from the "shared" v8 instance. I have to note that I don't have a clue on how these things work under the hood though. Since it's working good (my problem at least) in Canary, is it only to wait until that is turned into stable? Or is this thread actually helpful finding problems in the current Chrome version? In the meantime, is it possible to force a new v8-context without leaving the domain on a page refresh? At least when developing. 

Deleted: Screen Shot 2018-02-14 at 10.14.17.png 200 KB

	Screen Shot 2018-02-14 at 10.14.17.png 200 KB View Download

CC'ing possible dev's form the  issue 810701 

@yukishiino: Can you please confirm is this issue is as same as  issue 810701 ?

Thanks!!

The url to interland if you want to test reloading that one is: https://beinternetawesome.withgoogle.com/interland/kind-kingdom. But I think the problem occur on any site. google.com for example (see screenshot) 

Deleted: Screen Shot 2018-02-14 at 12.16.52.png 150 KB

	Screen Shot 2018-02-14 at 12.16.52.png 150 KB View Download

I think that this issue is a dup of  Issue 810701  .

re #c12: google.com is currently showing a series of special doodles that use webaudio.  Other sites that don't use webaudio look to me having no problem.