1271397 - OOM when accessing input.value in a loop

Status: NEW

(Core :: DOM: Editor, defect, P5)

Description

[Jim Mathies [:jimm]]

Attachment: 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

Comment 1

[Andrew McCreight [:mccr8]]

This is likely a JS or DOM issue.

Comment 2

[Jan de Mooij [:jandem]]

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?

Comment 3

[Mayank Bansal]

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

[Mayank Bansal]

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

[Jan de Mooij [:jandem]]

(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.

Comment 6

[Jan de Mooij [:jandem]]

Attachment: Different testcase

Modified test with some instructions. It doesn't use parseInt.

Comment 7

[Jan de Mooij [:jandem]]

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

Comment 8

[Jan de Mooij [:jandem]]

Needinfo from a random Gecko/CC expert.

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

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

Comment 10

[Olli Pettay [:smaug][[e-mail]]]

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

[Jon Coppeard (:jonco)]

I couldn't reproduce this when I tried yesterday.  Thanks Jan for figuring it out.

Comment 12

[Boris Zbarsky [:bzbarsky]]

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

[Olli Pettay [:smaug][[e-mail]]]

I wonder if Editor could just use nsIDocument::GetCachedEncoder() or some such.

Comment 14

[Jens Stutte [:jstutte]]

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.