OOM when accessing input.value in a loop

NEW
Unassigned

Status

()

Core
Editor
2 years ago
2 years ago

People

(Reporter: jimm, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(e10s-, firefox49 affected)

Details

Attachments

(2 attachments)

(Reporter)

Description

2 years ago
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.
Component: DOM: Content Processes → JavaScript Engine
Summary: OOM | small triggered using parseInt under e10s → OOM in loop with parseInt()
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

2 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

2 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.
(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)
Created attachment 8751157 [details]
Different testcase

Modified test with some instructions. It doesn't use parseInt.
Flags: needinfo?(jdemooij)
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
Needinfo from a random Gecko/CC expert.
Flags: needinfo?(bugs)

Updated

2 years ago
Summary: OOM in loop with parseInt() → OOM when accessing input.value in a loop

Comment 9

2 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)
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.
(Reporter)

Updated

2 years ago
tracking-e10s: ? → -
You need to log in before you can comment on or make changes to this bug.