1317960 - Unity WebGL consuming too much memory, causing 'Out of memory' error

Status: UNCONFIRMED

(Core :: DOM: Core & HTML, defect, P3)

Description

[Satbir Singh]

Attachment: merge_file_11.jpg

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.99 Safari/537.36

Steps to reproduce:

1. Launch firefox, open URL http://beta.unity3d.com/jonas/AngryBots/  and let it download.
2. Open Task Manager add-on(https://addons.mozilla.org/en-US/firefox/addon/task-manager/) and observe memory. (In my system its 600+ 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.


Actual results:

1. Browser is getting out of memory, when memory exceeding a threshold (threshold differs from system to system).


Expected results:

1. Memory should not increase progressively and consume only as much as first launch.

Comment 1

[Peter Chang[:pchang]]

Could you attach the information from about:memory?

Comment 2

[Satbir Singh]

Attachment: memory-report_2016Nov17.zip

Please find attachment memory-report_2016Nov17.zip . The issue reproducable when refreshing page and I took some memory shots while refreshing page.

Comment 3

[Peter Chang[:pchang]]

The following is the diff from attachment 8811686 [details].
I saw there was additional 658 MB memory usage from app side.

Reporter, are you able to simplify the test case?

│  │  │  ├──-658.83 MB (132.92%) -- js-compartment(http://beta.unity3d.com/jonas/AngryBots/)
│  │  │  │  ├──-658.16 MB (132.78%) -- classes
│  │  │  │  │  ├──-572.59 MB (115.52%) -- class(ArrayBuffer)/objects
│  │  │  │  │  │  ├──-572.59 MB (115.52%) -- malloc-heap/elements
│  │  │  │  │  │  │  ├──-512.00 MB (103.30%) ── asm.js [2] [-]

Comment 4

[Satbir Singh]

@Peter, What do you mean by 'simplify test case'? Do you want me to create another smaller size app for debugging?

Comment 5

[Peter Chang[:pchang]]

> @Peter, What do you mean by 'simplify test case'? Do you want me to create
> another smaller size app for debugging?
So far I don't think this is necessary.

Stabir, I just tried to reproduce this in my machine and found the following memory report.
You could see total 600 MB+ memory usage by AngryBots and half of them were used by a detached windows(before refresh one). Therefore, I would say this is related to GC/CC timing. I would recommend you to use about:memory to capture memory because I sometime see wrong number reported from task manager.
 

│  │    ├──314.16 MB (12.06%) -- detached
│  │    │  ├──312.77 MB (12.00%) -- window([system])
│  │    │  │  ├──312.77 MB (12.00%) -- js-compartment(http://beta.unity3d.com/jonas/AngryBots/)
│  │    │  │  │  ├──312.33 MB (11.99%) -- classes
│  │    │  │  │  │  ├──286.30 MB (10.99%) -- class(ArrayBuffer)/objects
│  │    │  │  │  │  │  ├──256.00 MB (09.83%) ── non-heap/elements/asm.js
│  │    │  │  │  │  │  ├───30.30 MB (01.16%) ── malloc-heap/elements/normal
│  │    │  │  │  │  │  └────0.00 MB (00.00%) ── gc-heap
│  │    │  │  │  │  └───26.04 MB (01.00%) ++ (9 tiny)
│  │    │  │  │  └────0.43 MB (00.02%) ++ (6 tiny)
│  │    │  │  └────0.00 MB (00.00%) ++ dom
│  │    │  └────1.39 MB (00.05%) ++ (2 tiny)
│  │    └───28.82 MB (01.11%) ++ ghost
│  ├────340.39 MB (13.06%) -- top(http://beta.unity3d.com/jonas/AngryBots/, id=2147484856)/active/window(http://beta.unity3d.com/jonas/AngryBots/)
│  │    ├──339.33 MB (13.02%) -- js-compartment(http://beta.unity3d.com/jonas/AngryBots/)
│  │    │  ├──336.59 MB (12.92%) -- classes
│  │    │  │  ├──291.23 MB (11.18%) -- class(ArrayBuffer)/objects
│  │    │  │  │  ├──256.00 MB (09.83%) ── non-heap/elements/asm.js
│  │    │  │  │  ├───35.22 MB (01.35%) ── malloc-heap/elements/normal
│  │    │  │  │  └────0.00 MB (00.00%) ── gc-heap(In reply to Satbir Singh from comment #4)

Comment 6

[Satbir Singh]

@Peter: Can you give me an idea on how to capture about:memory repeatedly while page is getting refresh? From default about:memory, i'll have to use button "Measure and save", which takes time, to measure & pops-up a save dialog box.

Comment 7

[Peter Chang[:pchang]]

(In reply to Satbir Singh from comment #6)
> @Peter: Can you give me an idea on how to capture about:memory repeatedly
> while page is getting refresh? From default about:memory, i'll have to use
> button "Measure and save", which takes time, to measure & pops-up a save
> dialog box.

How about open two tab for about:memory? And then run "measure" before demo and after demo?

Comment 8

[Satbir Singh]

Attachment: zip file contains 3 files. Memory-report-before demo, after-demo and on-refresh-tab.

Comment 9

[Peter Chang[:pchang]]

The following were memory report for AngryBots. It looks like this app could occupy up to 600 MB. During refresh, the detached windows still kept alive for a while and the total windows object occupied around 1000 MB. I didn't see anything we could do in graphic side.

├──339.96 MB (64.43%) -- window-objects
│  ├──338.94 MB (64.24%) -- top(http://beta.unity3d.com/jonas/AngryBots/, id=2147483649)
│  │  ├──331.53 MB (62.83%) ++ active/window(http://beta.unity3d.com/jonas/AngryBots/)
│  │  └────7.42 MB (01.41%) ++ (2 tiny)

├──674.14 MB (68.24%) -- window-objects
│  ├──673.21 MB (68.15%) -- top(http://beta.unity3d.com/jonas/AngryBots/, id=2147483649)
│  │  ├──665.70 MB (67.39%) -- active/window(http://beta.unity3d.com/jonas/AngryBots/)
│  │  │  ├──665.42 MB (67.36%) ++ js-compartment(http://beta.unity3d.com/jonas/AngryBots/)
│  │  │  └────0.29 MB (00.03%) ++ (4 tiny)


├──1,042.34 MB (70.26%) -- window-objects
│  ├────658.91 MB (44.41%) -- top(none)/detached/window([system])
│  │    ├──658.83 MB (44.41%) -- js-compartment(http://beta.unity3d.com/jonas/AngryBots/)
│  │    │  ├──658.16 MB (44.36%) ++ classes
│  │    │  └────0.67 MB (00.05%) ++ (5 tiny)
│  │    └────0.08 MB (00.01%) ++ (2 tiny)
│  ├────382.58 MB (25.79%) ++ top(http://beta.unity3d.com/jonas/AngryBots/, id=2147483649)

Comment 10

[Peter Chang[:pchang]]

Possible related to DOM?

Comment 11

[Hsin-Yi Tsai (she/her) [:hsinyi]]

Hi Boris, do you think this is something related to GC timing? Any more ideas? Thank you.

Comment 12

[Satbir Singh]

Hi,
Any progress on this bug?

Comment 13

[Boris Zbarsky [:bzbarsky]]

> Hi Boris, do you think this is something related to GC timing?

If you take a page that's using 400MB, then unload it and load another page that's using 400MB, then you will be using 800MB until a GC happens and the now-unloaded page's objects are collected.  Is that what you were asking?  ;)

Comment 14

[Andrew Overholt [:overholt]]

Luke, have you seen anything like this before? It seems like reloading is causing multiple copies of the asm.js arraybuffer to be in memory simultaneously but we're not forcing a GC. Andrew McCreight thinks we have some mechanism that should force a GC here.

Comment 15

[Luke Wagner [:luke]]

Andrew's right; we have a callback:
  https://hg.mozilla.org/mozilla-central/file/tip/js/src/jsapi.h#l6200
that we call if a large allocation fails (viz., for ArrayBuffers):
  http://searchfox.org/mozilla-central/source/js/src/vm/Runtime.cpp#832
and this callback triggers the low-memory pressure event which should perform a synchronous GC/CC/GC (which, because of the low-memory event, should nuke everything except active documents).

One thing suspicious-looking in comment 9 is the "top(none)/detached/window([system])".  Last time I saw one of these there was some legitimate leak that was keeping the window alive which, transitively, keeps the big expensive old ArrayBuffers around.  Perhaps we could provide instructions for collecting a CC dump?

Comment 16

[Andrew Overholt [:overholt]]

Andrew said he'd try to reproduce and see where/if we're leaking.

Comment 17

[Andrew McCreight [:mccr8]]

The callback in comment 15 might be going wrong here. I'm not really familiar enough with it to investigate, I think. Sorry for the long delay here.