Page with WebGL build. After page update, the memory is not cleared. Memory is accumulated and increased.
Hi!
We have an issue with a page with WebGL build. After page update, the memory is not cleared. Memory is accumulated and increased.
So, the basic WTR is: - Open project in Firefox ( I use 57.0 64-bit, but it reproducible in 55.0.3 32-bit as well ). Link to the project: http://testsrv.plrm.zone/webgltestproject/ - Open Windows `Task Manager`. - See something like ~700 MB in Memory category for firefox.exe process. - In browser window press F5. - See memory increase. - Repeat F5.
It can really blow up RAM, for example, here is memory consumption after 10+ refreshes: http://prntscr.com/haomtc
It is looks like a fundamental bug of FF.
I made all described in article steps. And the bug still occurs: https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems
Opaite Mbohovái (8)
Memory consumption does go up but it it is released straight away after the demo runs. I am not able to see a growth in memory after refreshes. Can you try reproducing the issue on Nightly version, https://www.mozilla.org/en-US/firefox/channel/desktop/
Hi!
We have reproduced.
1. Firefox 56.0.1 (64-bit): https://prnt.sc/hh9hg1
2. Firefox Nightly 59.0a1 (64-bit): https://prnt.sc/hh9kra https://prnt.sc/hh9irk
I am going to ask someone using Windows to takeover since I cannot reproduce the error on Linux and this might be related to Windows and the specific graphics card you have.
Can you update your driver from https://downloadcenter.intel.com/product/81496 by choosing the appropriate platform. It might fix your problems.
Edit: Corrected the download link (thanks Tonnes).
Moambuepyre jagan605 rupive
Hello! Sorry for late answer.
``` Hi!
We have reproduced.
1. Firefox 56.0.1 (64-bit): https://prnt.sc/hh9hg1
2. Firefox Nightly 59.0a1 (64-bit): https://prnt.sc/hh9kra https://prnt.sc/hh9irk
```
Actually we have reproduced on computer with AMD processor and NVIDIA GeForce GTX 650 video adapter. But we updated drivers and on Nightly version we can't reproduced problem. On Firefox 56.0.1 (64-bit) is still occurs: https://prnt.sc/hmxtt1
56 is currently not supported but you can test 57 to see if the fix was backported.
We have checked on Firefox 57.0.2 (64-bit). Bug is still occurs: https://prnt.sc/hndnc5
And we have reproduced problem in Nightly version `59.0a1(2017-11-29)(64-bit)`: https://prnt.sc/hndpfm
Suppose, that it is floating bug (that occurs from to time).
Tried this out on my macOS 10.12.6 Macbook Pro laptop, on both
Firefox 57.0.1 (64-bit) and Firefox Nightly 59.0a1 (2017-12-14) (64-bit)
with STR:
1. Open up browser afresh, with one tab open 2. Navigate to http://testsrv.plrm.zone/webgltestproject/ 3. Click on the page reload button 4. Goto step 2 for ~10 times 5. After 10 reloads, while the Unity page is open, navigate to about:memory in a second tab 6. Click on Measure and find the "Web Content (pid xxxyyyzzz)" process 7. Check the total memory usage of the tree, e.g. 865.09 MB (100.0%) -- explicit
I see that if I keep reloading the page quickly, there are multiple instances of the page in memory at one time, (got 4 instances at max, for about 4*7=2.8GB of RAM usage), but after a while, they get reclaimed as part of the garbage collection process. Multiple pages are typically kept open for some period of time for fast back navigation.
Other observations regarding this:
- after step 5 and before 6, clicking on "Free Memory - GC" in the about:memory page and then doing the Measure, I always saw only one copy of the page in memory, suggesting that the garbage collector properly has a hold of the old pages (and will be able to naturally reclaim them at some point later at will, as opposed to something pinning the memory down) - in Firefox Nightly, it looks like GC reclaiming is being done a bit more aggressively, and I only ever saw 2 copies of the page in memory at a time (the current instance, and one old instance for back navigation) - reloading the page some 20 times, I was never able to get an out of memory error, suggesting that GC is properly freeing up the memory once it is not needed, rather than being extravagantly lazy to ever reclaim - from prior experience, I do recall that if one has the browser Developer Tools window open with Console tab or Debugger tab, that can pin down old pages, because the Debugger can be accessing these. For that effect, it is best to keep the Developer Tools window closed when debugging memory usage in scenarios like this (not sure if this might have applied here, but just in case)
Some questions to help further debug to the root cause:
- when such high memory usage scenario occurs, is it possible to reload the page so many times that eventually the browser runs out of memory and is unable to load the Unity page? - when there are several copies of the page in memory, how does that memory behave when opening about:memory and clicking on the "Free Memory - GC, CC, Minimize memory usage" buttons? Does that reduce the memory usage, or does memory usage stay high? - when there are several copies of the page in memory, what happens when one closes that tab altogether? (while having e.g. an empty tab open in the background so that the whole browser doesn't quit) Does the used memory free up after a while then, or does it remain in memory?
My impression here is that you are seeing the effect of garbage collection occurring lazily, especially if hammering the page reload button quickly, but that the memory will eventually go away once GC kicks in.