On Nightly, when I do 1. Load http://www.unrealengine.com/html5/ 2. Press run 3. Wait until it finishes starting up (when you are in the market, there is a big popup dialogue, and user input can do stuff), then close the tab 4. Wait, minimize memory use in about memory, etc., then check memory use. I then see 1,522.21 MB (100.0%) -- explicit ├──1,287.23 MB (84.56%) -- js-non-window │ ├──1,256.79 MB (82.56%) -- runtime │ │ ├──1,233.18 MB (81.01%) ── temporary │ │ └─────23.62 MB (01.55%) ++ (11 tiny) │ ├─────24.70 MB (01.62%) ++ zones │ └──────5.74 MB (00.38%) ++ gc-heap 1.2GB is being held onto, even after the tab is closed. Are we leaking all the parse nodes or something like that?
"temporary" isn't very descriptive...
> "temporary" isn't very descriptive... But, as usual, the tool-tip in about:memory for "temporary" is descriptive. This is parse nodes.
Whiteboard: [MemShrink] → [MemShrink][games:p1]
Summary: 1.2GB of Epic Citadel demo is leaked → 1.2GB of parse nodes leaked in Epic Citadel demo
This is almost certainly a regression, because we looked carefully at memory use a few months ago around GDC, and would have seen this.
Works: ftp://ftp.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-linux64/1369916732/ rev http://hg.mozilla.org/integration/mozilla-inbound/rev/87bbe2a5b08a Fails: ftp://ftp.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-linux64/1369917031/ rev http://hg.mozilla.org/integration/mozilla-inbound/rev/d71234d65e90
Does this still repro after the fix for bug 878293? That bug could cause mark/release calls on the allocator used for parse nodes to be mismatched, which would break the checks used to immediately release the allocator's memory after a giant parse.
You're right, this no longer happens in today's nightly.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 878293
You need to log in before you can comment on or make changes to this bug.