Created attachment 8750424 [details] hangit.html 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
This is likely a JS or DOM issue.
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?
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
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.
(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.
Created attachment 8751157 [details] Different testcase Modified test with some instructions. It doesn't use parseInt.
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
Needinfo from a random Gecko/CC expert.
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
But, we could also try to delete snowwhite objects when we're close to OOM, if we just have a way to detect that.
I couldn't reproduce this when I tried yesterday. Thanks Jan for figuring it out.
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....
I wonder if Editor could just use nsIDocument::GetCachedEncoder() or some such.