Closed
Bug 878166
Opened 11 years ago
Closed 11 years ago
1.2GB of parse nodes leaked in Epic Citadel demo
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 878293
People
(Reporter: azakai, Unassigned)
References
(Blocks 1 open bug)
Details
(Keywords: regression, Whiteboard: [MemShrink][games:p1])
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?
Reporter | ||
Updated•11 years ago
|
Blocks: gecko-games
Whiteboard: [MemShrink]
Comment 1•11 years ago
|
||
"temporary" isn't very descriptive...
Comment 2•11 years ago
|
||
> "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]
Updated•11 years ago
|
Summary: 1.2GB of Epic Citadel demo is leaked → 1.2GB of parse nodes leaked in Epic Citadel demo
Reporter | ||
Comment 3•11 years ago
|
||
This is almost certainly a regression, because we looked carefully at memory use a few months ago around GDC, and would have seen this.
Keywords: regression
Comment 4•11 years ago
|
||
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
Blocks: LazyBytecode
Flags: needinfo?(bhackett1024)
Comment 5•11 years ago
|
||
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.
Flags: needinfo?(bhackett1024)
Comment 6•11 years ago
|
||
You're right, this no longer happens in today's nightly.
Updated•11 years ago
|
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•