1255568 - Memory footprint of web game grows between every hard refresh

Status: NEW

(DevTools :: Memory, defect, P3)

Description

[Jordan Santell [:jsantell] [@jsantell]]

Working on one of our partner's games, I'm noticing the memory footprint grow inbetween refreshes, as if something isn't being cleaned up in the platform.

STR:
1: open memory tools, enable allocations
2: Go to http://tanx.playcanvas.com (or can provide local source privately)
3: Wait til your tank spawns, take a snapshot
4: Take note of the size of snapshot
5: Hard refresh and go back to step 3

On every repetition, the footprint seems to grow by ~20MB and the current views aren't clear on where the issue is (seems to be a lot of things without allocation stacks, or everything grows proportionally). The SavedFrames count seems to get higher than I expected. Recording allocation stacks doesn't seem to make a difference.

I'll attach two snapshots that are from an example first load, and the corresponding 10th or so load, with a difference of 25MB vs 250MB or so.

Comment 1

[Jordan Santell [:jsantell] [@jsantell]]

Attachment: firstrun.fxsnapshot

First snapshot taken after game is loaded in a new tab.

Comment 2

[Jordan Santell [:jsantell] [@jsantell]]

Nevermind, subsequent snapshots are too large to attach on here. But it is recreateable.

Comment 3

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Attachment: baseline

Comment 4

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Attachment: comparison after 4 refreshes

Comment 5

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

I can repro without enabling allocation stack recording.

Comment 6

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

5 refreshes, with allocation stacks: http://media.fitzgeraldnick.com/dumping-grounds/tanx-with-stacks.fxsnapshot

The original was ~20mb, this is ~75mb. Dominator tree shows that most of the memory is tied up in some kind of `window.app.assets` structure, and much of the children dominated by that were allocated in a `_parseAssets` method. I think this is a legit leak in Tanx itself, but it is hard to make further progress without the unminified source.

Can we find people who originally wrote this, debug it with them, and write up a case study?

Comment 7

[Jordan Santell [:jsantell] [@jsantell]]

Building the unminified source to get more info; I'll reach out to them, I think they'll be at GDC next week.

Comment 8

[Greg Tatum [:gregtatum] (REO Fx132)]

Attachment: Wandering Lines Screenshot

I have seen this behavior as well on a visualization I've been running the memory tool on a bunch. You can see in the dominator tree view there is an "objects > Function" with retained sizes of 13mb and 10mb respectively. These are both retained between refreshes.

Live URL: http://gregtatum.com/poems/wandering-lines/
Code: https://github.com/TatumCreative/wandering-lines

Recording allocation stacks on the un-minified code it looks like this is what is being retained:
https://github.com/TatumCreative/wandering-lines/blob/master/index.js#L170-L174

Is the requestAnimationFrame somehow retaining the reference between refreshes?

Comment 9

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

Each refresh uses a different JSCompartment, meaning that it gets a different global object, JSScripts are recreated, etc... It should be impossible for something in the new compartment to reference and hold alive anything from the old compartment.

Comment 10

[Jordan Santell [:jsantell] [@jsantell]]

Seeing it here too: https://wfwalker.github.io/mc-choir/

This just decodes a handful of small mp3s as arraybuffers -- it looks like the arraybuffers stick around when using the tool. In about:memory, the window stays alive long after the tab is closed, and with it arraybuffers from several refreshes. Does not happen if you don't use the tool. I think this should be a higher priority since this could be sucking up memory long after a developer is done debugging. 

This page uses services workers, so that could play a part, but the mp3s cached are small; its the decoded arraybuffers that get huge. These could be platform bugs, but starting to feel like the tool is causing it.

Comment 11

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

(In reply to Jordan Santell [:jsantell] [@jsantell] (Please needinfo) from comment #10)
> Seeing it here too: https://wfwalker.github.io/mc-choir/
> 
> This just decodes a handful of small mp3s as arraybuffers -- it looks like
> the arraybuffers stick around when using the tool. In about:memory, the
> window stays alive long after the tab is closed, and with it arraybuffers
> from several refreshes. Does not happen if you don't use the tool. I think
> this should be a higher priority since this could be sucking up memory long
> after a developer is done debugging. 
> 
> This page uses services workers, so that could play a part, but the mp3s
> cached are small; its the decoded arraybuffers that get huge. These could be
> platform bugs, but starting to feel like the tool is causing it.

In this test case, it is ArrayBuffers that are leaking as we keep refreshing. All of them are considered roots with a mJSChannels[i] edges which is something related to media. Looks like this is a platform leak to me. I tried doing an about:memory "minimize memory usage" and it had no effect.

https://dxr.mozilla.org/mozilla-central/search?tree=mozilla-central&q=mJSChannels

Paul, any idea why repeatedly refreshing the page from comment 10 would lead to ArrayBuffer objects being retained for a long time via mJSChannels[i] edges?

Comment 12

[Paul Adenot (:padenot)]

Probably a bug ? I think those would be from `decodeAudioData` or something.