Open
Bug 1271397
Opened 8 years ago
Updated 3 years ago
OOM when accessing input.value in a loop
Categories
(Core :: DOM: Editor, defect, P5)
Core
DOM: Editor
Tracking
()
NEW
People
(Reporter: jimm, Unassigned)
Details
Attachments
(2 files)
I was putting this test case together for another bug and started reliably hitting OOM | small crashes playing with it. Oddly enough the value you use in the text input seemed to play a role. A value of say 7,000,000,000 hit the crash reliably, but a value of 8000000000 didn't. bp-bbde9bd6-3dd3-4bb1-8176-639712160509 5/9/2016 1:53 PM bp-c879def6-a6d6-48c9-98aa-1c05c2160509 5/9/2016 1:53 PM bp-c34584af-24d9-4f5b-9349-c4a532160509 5/9/2016 1:52 PM bp-671c85e1-0497-4ca1-a5ee-f0a852160509 5/9/2016 1:48 PM bp-d0894334-17e8-497c-8d7c-d97902160509 5/9/2016 1:47 PM bp-176f136f-f0de-45c4-974d-192002160509 5/9/2016 1:47 PM
Comment 1•8 years ago
|
||
This is likely a JS or DOM issue.
Component: DOM: Content Processes → JavaScript Engine
Summary: OOM | small triggered using parseInt under e10s → OOM in loop with parseInt()
Comment 2•8 years ago
|
||
I'm unable to reproduce this reliably on OS X or Windows with a recent Nightly + clean profile. I think it happened once on OS X (content process used > 30 GB), but usually memory usage stays below 150 MB. Anyone else able to reproduce this? Maybe GC gets stuck somehow?
Flags: needinfo?(jcoppeard)
Comment 3•8 years ago
|
||
can repro this reliably on windows. Str: 1. open the testcase. 2. Add two "0" to the number 3.press go 4. A dialog box appears. Click on start 5. Memory of that content-process high. OOM crash. https://crash-stats.mozilla.com/report/index/bp-a98ed22d-b164-4c86-baf0-287152160510 https://crash-stats.mozilla.com/report/index/bp-e5ee046d-b462-4084-a555-a50e52160510 https://crash-stats.mozilla.com/report/index/bp-d79301a7-6f03-49fa-aa0a-11fd72160510
Comment 4•8 years ago
|
||
FWIW, the value "8000000000" mentioned in comment #1 crashed the browser for me. While the default value in the testcase set the tab in 100% CPU use,but neither the tab used much RAM, nor it crashed.
Comment 5•8 years ago
|
||
(In reply to mayankleoboy1 from comment #3) > 2. Add two "0" to the number Ah that seems to work. Thanks! I'll take a look tomorrow.
Flags: needinfo?(jcoppeard) → needinfo?(jdemooij)
Comment 6•8 years ago
|
||
Modified test with some instructions. It doesn't use parseInt.
Flags: needinfo?(jdemooij)
Comment 7•8 years ago
|
||
Based on some profiles, I think this is a cycle collector issue. After the test finishes we release the memory but we spend seconds under: * SnowWhiteKiller::~SnowWhiteKiller * nsDocumentEncoder::~nsDocumentEncoder * nsPlainTextSerializer::Release
Component: JavaScript Engine → DOM
Updated•8 years ago
|
Summary: OOM in loop with parseInt() → OOM when accessing input.value in a loop
Comment 9•8 years ago
|
||
So this would be effectively similar to while(true) document.body.innerHTML = "<div>"; where we create tons of garbage but don't have a chance to collect it. I'd say this is a missing optimization in Editor, at least given the current HTMLInputElement implementation. http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/nsPlaintextEditor.cpp#1293 http://mxr.mozilla.org/mozilla-central/source/editor/libeditor/nsPlaintextEditor.cpp#1238
Component: DOM → Editor
Flags: needinfo?(bugs)
Comment 10•8 years ago
|
||
But, we could also try to delete snowwhite objects when we're close to OOM, if we just have a way to detect that.
Comment 11•8 years ago
|
||
I couldn't reproduce this when I tried yesterday. Thanks Jan for figuring it out.
Comment 12•8 years ago
|
||
We could try to have mozalloc_handle_oom do something, but that might be too late in cases when the object dtors would need to allocate, right? The specific case here might be handled by caching the document encoder and serializer; that's the part that we keep allocating, I think....
Comment 13•8 years ago
|
||
I wonder if Editor could just use nsIDocument::GetCachedEncoder() or some such.
Reporter | ||
Updated•8 years ago
|
Comment 14•3 years ago
|
||
Bulk-downgrade of unassigned, 4 years untouched DOM/Storage bugs' priority.
If you have reason to believe this is wrong (especially for the severity), please write a comment and ni :jstutte.
Severity: normal → S4
Priority: -- → P5
You need to log in
before you can comment on or make changes to this bug.
Description
•