Unity WebGL taking consuming too much memory, causing Out of memory error
Reported by
ig.sat...@gmail.com,
Nov 16 2016
|
|||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0 Steps to reproduce the problem: 1. Launch chrome, open URL http://beta.unity3d.com/jonas/AngryBots/ and let it download. 2. Open Chrome's Task Manager and observe memory. (In my system its 500+ MB) 3. Now hit refresh(via button on browser or F5), and as soon as browser refresh page & start downloading content again, for some time, memory rises(in my case, memory increased to 800+MB). Let game download again. 4. Now, memory consumption reduced to 400+MB again, which is normal. 5. As soon as game starts again, refresh page again. This time, while still downloading game, the memory consumption is more that as compared to Step#3 (in my case 1,000+MB). At this point of time, i am getting Out of memory error from browser. What is the expected behavior? 1. Memory should not increase progressively and consume only as much as first launch. What went wrong? 1. Browser is getting out of memory, when memory exceeding a threshold (threshold differs from system to system). Did this work before? N/A Does this work in other browsers? N/A Chrome version: 54.0.2840.99 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 23.0 r0
,
Nov 17 2016
Able to reproduce the issue on Windows 7,Mac 10.11.6 & Linux ubuntu 14.04 using chrome stable version-54.0.2840.99/98/100 as per the steps in Comment#0. Tested the same issue in latest Dev -56.0.2914.3 , observed Game is paused when we open 'Task manager'. Reporter@ can you please confirm whether we can consider Dev -56.0.2914.3 as good build or bad build. Please find the attached stable & dev screen casts for reference. Thank you.
,
Nov 17 2016
Issue reproducable in stable version. PFA the screen cast.
,
Nov 17 2016
On Command#2: 1. You can open 'Task Manager' and Chrome side by side to check effect. Please see attached image and keep your focus on chrome game. 2. I couldn't found Chrome Dev -56.0.2914.3, but i tested for bug again on 55.0.2883.52 beta (64-bit) and still reproducable. Do you have any plan on working on this issue sooner?
,
Nov 17 2016
As per #4,if the issue is reproducible in M55 Beta, I assume we should get a reverse bisect and patch it to M55.
,
Nov 17 2016
A friendly reminder that M55 Stable is launch is coming soon! Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and get it merged into the release branch ASAP so it gets enough baking time in Beta (before Stable promotion). Thank you! Also due to Thanksgiving holidays in US, please make sure fix is ready and merged to M55 latest by 5:00 PM PT Wednesday, 11/23/16 (sooner the better).
,
Nov 18 2016
Rechecked this on chrome version stable 54.0.2840.99, Dev 56.0.2914.3 on Windows 10. Below are the observations: 1) On both versions of chrome, observed a consistent increase in memory when ever there was a refresh operation performed. 2) Memory returned to normal (500+ MB) once the refreshing operation was completed (After 30 to 40 Seconds). 3) Never got an Out of memory error, tried multiple times(at least 20 to 25 Attempts). 2 Systems(Windows 10) were used which processed 8GB and 16GB RAM. 4) Also tried the same on M43 (43.0.2357.134) and same behavior was observed. Attached screen shots where the memory increase was observed on all the three versions of chrome used. P.S: On M43 memory utilization was (600+ MB) once the refresh operation was completed. Assuming that this is not a regression issue, hence removing bisect and Blocker label. Also changing Milestone from M55 to M56. Kindly update us if any other information's are required. Thanks.!
,
Nov 18 2016
Untriaged it so that it gets addressed.
,
Nov 18 2016
On Comment#7: tab gets crash very frequently for low end machine with 2GB or less RAM. I have a system with 8GB RAM but after some refreshes, it gets crashed eventually. Comment#8: I get that, this bug is going to be fix in chrome v56. Is there any tentative date for Chrome v56 launch or even beta so, i can test? My product users are dependent on this bug resolution. Thanks!!!
,
Nov 18 2016
,
Nov 21 2016
Is this the same issue as has been reported before about the asm.js heap taking up too much memory? Is the primary issue that the underlying ArrayBuffer isn't being GC'd eagerly enough upon page reload?
,
Nov 21 2016
I think the 600MB reported above is very likely to be the parser memory. That's been improved a lot this milestone, but is still a problem. The plan is to fix this in M57 with the asm.js validator.
,
Dec 13 2016
Changing to M57 milestone as per comment 12.
,
Jan 12 2017
Issue 419179 has been merged into this issue.
,
Jan 20 2017
P1 bug ping, any update on the plan from #12?
,
Apr 7 2017
Hi, Is there any progress on this bug?
,
Jun 9 2017
bradnelson@ this sounds like a WebAsm issue. Removing GPU categories. Please change if you think this is on WebGL side.
,
Mar 12 2018
Hi developers, Is there any progress on this bug? I am using chrome v64.x and still able to reproduce the issue.
,
Jan 16
This is a big app, so it will spike memory, and sometimes go OOM on smaller machines. I don't think we are leaking memory (anymore). I just successfully completed 10x reloads in a row and peaked at about 580Mb of memory, according to the task manager. Closing as fixed. |
|||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||
Comment 1 by ligim...@chromium.org
, Nov 16 2016Components: Internals>GPU>WebGL
Labels: -Pri-2 ReleaseBlock-Stable Needs-Triage-M54 M-54 Needs-Bisect Pri-1