Closed Bug 1282322 Opened 8 years ago Closed 2 years ago

Firefox crashes badly when unresponsive script warnings are kept

Categories

(Core :: Layout, defect, P3)

50 Branch
x86
Windows 7
defect

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: mirh, Unassigned)

References

()

Details

(Whiteboard: [MemShrink:P3])

Attachments

(2 files)

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:48.0) Gecko/20100101 Firefox/48.0
Build ID: 20160623122823

Steps to reproduce:

1. I disabled e10s in latest firefox portable nightly
2. I opened http://web.archive.org/web/*/http://psx-scene.com/*
3. After a while I get an unresponsive script warning


Actual results:

If I continue to press "continue", without checking the "don't ask again" box, after a bunch of warnings firefox crashes (probably 32 bit maximum allocable memory limit is hit)


Expected results:

It shouldn't have crashed. 
When I remove the warnings or when e10s is enabled it simply works (and surprisingly even with an inferior memory footprint).
Severity: normal → minor
OS: Unspecified → Windows 7
Hardware: Unspecified → x86
Attached file memory-report.json.gz
wow, that's a ton of heap-unclassified
Crash report agrees that this appears to be a layout issue:
https://crash-stats.mozilla.com/report/index/ed40eddf-62f5-4a9a-9ca4-b08732160629
Component: Untriaged → Layout
Product: Firefox → Core
Whiteboard: [MemShrink]
It's weird that you got heap-unclassified, I got lots of memory being used in layout in my memory report. This looks like a gigantic page. Do other browsers do better than us on this page?
I really wouldn't know. Explorer crashes with even smaller pages and legends say Chrome is as memory hungry as possible. 

What I'm sure is that e10s REALLY smooths thing, even consuming less RAM (2.8GB vs 3.2 iirc). 
x64 version on the other hand can't even manage to load the whole thing under 4.4GB (and then I have to kill it because I end physical memory)
I try to repro on Windows with DMD to figure out the heap-unclassified.
Flags: needinfo?(erahm)
Whiteboard: [MemShrink] → [MemShrink:P3]
On a 64-bit build I had about 1GB of heap-unclassified while loading the page. Half of that has no stack (due to sampling), the primary culprit appears to be |nsHtml5TreeOpStage::MoveOpsAndSpeculativeLoadsTo| [1] which managed to allocate a 460MB array. The rest of the top offenders all seem to be coming through the nsHtml5StreamParser.

Regarding the origins of heap-unclassified it seems to be due to not reporting memory used while parsing.

More details:

> Unreported {
>   1 block in heap block record 2 of 7,716
>   461,373,440 bytes (461,373,440 requested / 0 slop)
>   22.81% of the heap (46.68% cumulative)
>   41.36% of unreported (84.66% cumulative)
>   Allocated at {
>     #01: nsTArray_base<nsTArrayInfallibleAllocator,nsTArray_CopyWithMemutils>::EnsureCapacity<nsTArrayInfallibleAllocator> (c:\dev\mozilla-central\obj-x86_64-pc-mingw32\dist\include\nstarray-inl.h:183)
>     #02: nsTArray_Impl<mozilla::media::Interval<mozilla::media::TimeUnit>,nsTArrayInfallibleAllocator>::AppendElements<mozilla::media::Interval<mozilla::media::TimeUnit>,nsTArrayInfallibleAllocator,nsTArrayInfallibleAllocator> (c:\dev\mozilla-central\obj-x86_64-pc-mingw32\dist\include\nstarray.h:2021)
>     #03: nsHtml5TreeOpStage::MoveOpsAndSpeculativeLoadsTo (c:\dev\mozilla-central\parser\html\nshtml5treeopstage.cpp:31)
>     #04: nsHtml5TreeOpExecutor::RunFlushLoop (c:\dev\mozilla-central\parser\html\nshtml5treeopexecutor.cpp:391)
>     #05: nsHtml5ExecutorFlusher::Run (c:\dev\mozilla-central\parser\html\nshtml5streamparser.cpp:130)
>     #06: nsThread::ProcessNextEvent (c:\dev\mozilla-central\xpcom\threads\nsthread.cpp:1058)
>     #07: NS_ProcessNextEvent (c:\dev\mozilla-central\xpcom\glue\nsthreadutils.cpp:290)
>     #08: mozilla::ipc::MessagePump::Run (c:\dev\mozilla-central\ipc\glue\messagepump.cpp:96)
>     #09: MessageLoop::RunHandler (c:\dev\mozilla-central\ipc\chromium\src\base\message_loop.cc:226)
>     #10: MessageLoop::Run (c:\dev\mozilla-central\ipc\chromium\src\base\message_loop.cc:206)
>     #11: nsBaseAppShell::Run (c:\dev\mozilla-central\widget\nsbaseappshell.cpp:158)
>     #12: nsAppShell::Run (c:\dev\mozilla-central\widget\windows\nsappshell.cpp:264)
>     #13: nsAppStartup::Run (c:\dev\mozilla-central\toolkit\components\startup\nsappstartup.cpp:285)
>     #14: XREMain::XRE_mainRun (c:\dev\mozilla-central\toolkit\xre\nsapprunner.cpp:4309)
>     #15: XREMain::XRE_main (c:\dev\mozilla-central\toolkit\xre\nsapprunner.cpp:4429)
>     #16: XRE_main (c:\dev\mozilla-central\toolkit\xre\nsapprunner.cpp:4520)
>     #17: do_main (c:\dev\mozilla-central\browser\app\nsbrowserapp.cpp:259)
>     #18: NS_internal_main (c:\dev\mozilla-central\browser\app\nsbrowserapp.cpp:392)
>     #19: wmain (c:\dev\mozilla-central\toolkit\xre\nswindowswmain.cpp:118)
>     #20: __scrt_common_main_seh (f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl:255)
>     #21: BaseThreadInitThunk[C:\Windows\system32\kernel32.dll +0x159bd]
>     #22: RtlUserThreadStart[C:\Windows\SYSTEM32\ntdll.dll +0x2a2e1]
>   }
> }
>
> Unreported {
>   259,512 blocks in heap block record 3 of 7,716
>   44,027,120 bytes (38,703,904 requested / 5,323,216 slop)
>   Individual block sizes: 2,048 x 125; 1,024 x 9,497; 512 x 748; 496 x 726; 480 x 644; 464 x 899; 448 x 909; 432 x 888; 416 x 1,220; 400 x 1,096; 384 x 1,249; 368 x 2,848; 352 x 2,592; 336 x 2,772; 320 x 4,235; 304 x 5,279; 288 x 6,956; 272 x 9,591; 256 x 11,706; 240 x 12,539; 224 x 10,281; 208 x 9,831; 192 x 7,222; 176 x 8,216; 160 x 8,511; 144 x 9,439; 128 x 333; 112 x 38; 96 x 6; 32 x 117,233; 16 x 11,883
>   2.18% of the heap (48.86% cumulative)
>   3.95% of unreported (88.61% cumulative)
>   Allocated at {
>     #01: nsStringBuffer::Alloc (c:\dev\mozilla-central\xpcom\string\nssubstring.cpp:218)
>     #02: nsAString_internal::MutatePrep (c:\dev\mozilla-central\xpcom\string\nstsubstring.cpp:133)
>     #03: nsAString_internal::ReplacePrepInternal (c:\dev\mozilla-central\xpcom\string\nstsubstring.cpp:195)
>     #04: nsAString_internal::ReplacePrep (c:\dev\mozilla-central\xpcom\string\nstsubstring.cpp:187)
>     #05: nsAString_internal::Replace (c:\dev\mozilla-central\xpcom\string\nstsubstring.cpp:563)
>     #06: nsHtml5Portability::newStringFromBuffer (c:\dev\mozilla-central\parser\html\nshtml5portability.cpp:24)
>     #07: nsHtml5Tokenizer::addAttributeWithValue (c:\dev\mozilla-central\parser\html\nshtml5tokenizer.cpp:348)
>     #08: nsHtml5Tokenizer::stateLoop<nsHtml5SilentPolicy> (c:\dev\mozilla-central\parser\html\nshtml5tokenizer.cpp:774)
>     #09: nsHtml5Tokenizer::tokenizeBuffer (c:\dev\mozilla-central\parser\html\nshtml5tokenizer.cpp:405)
>     #10: nsHtml5StreamParser::ParseAvailableData (c:\dev\mozilla-central\parser\html\nshtml5streamparser.cpp:1415)
>     #11: nsHtml5StreamParser::DoDataAvailable (c:\dev\mozilla-central\parser\html\nshtml5streamparser.cpp:1113)
>     #12: nsHtml5StreamParser::CopySegmentsToParser (c:\dev\mozilla-central\parser\html\nshtml5streamparser.cpp:1207)
>     #13: nsStringInputStream::ReadSegments (c:\dev\mozilla-central\xpcom\io\nsstringstream.cpp:249)
>     #14: nsHtml5StreamParser::OnDataAvailable (c:\dev\mozilla-central\parser\html\nshtml5streamparser.cpp:1187)
>     #15: nsDocumentOpenInfo::OnDataAvailable (c:\dev\mozilla-central\uriloader\base\nsuriloader.cpp:305)
>     #16: mozilla::net::nsHTTPCompressConv::do_OnDataAvailable (c:\dev\mozilla-central\netwerk\streamconv\converters\nshttpcompressconv.cpp:497)
>     #17: mozilla::net::nsHTTPCompressConv::OnDataAvailable (c:\dev\mozilla-central\netwerk\streamconv\converters\nshttpcompressconv.cpp:418)
>     #18: mozilla::net::nsHttpChannel::OnDataAvailable (c:\dev\mozilla-central\netwerk\protocol\http\nshttpchannel.cpp:6699)
>     #19: nsInputStreamPump::OnStateTransfer (c:\dev\mozilla-central\netwerk\base\nsinputstreampump.cpp:603)
>     #20: nsInputStreamPump::OnInputStreamReady (c:\dev\mozilla-central\netwerk\base\nsinputstreampump.cpp:430)
>     #21: nsOutputStreamReadyEvent::Run (c:\dev\mozilla-central\xpcom\io\nsstreamutils.cpp:97)
>     #22: nsThread::ProcessNextEvent (c:\dev\mozilla-central\xpcom\threads\nsthread.cpp:1058)
>     #23: NS_ProcessNextEvent (c:\dev\mozilla-central\xpcom\glue\nsthreadutils.cpp:290)
>     #24: mozilla::ipc::MessagePumpForNonMainThreads::Run (c:\dev\mozilla-central\ipc\glue\messagepump.cpp:338)
>   }
> }
>
> Unreported {
>   230,113 blocks in heap block record 4 of 7,716
>   33,833,808 bytes (29,115,028 requested / 4,718,780 slop)
>   Individual block sizes: 2,048 x 63; 1,024 x 7,677; 512 x 446; 496 x 618; 480 x 685; 464 x 721; 448 x 686; 432 x 685; 416 x 821; 400 x 855; 384 x 907; 368 x 1,205; 352 x 951; 336 x 1,555; 320 x 2,652; 304 x 2,841; 288 x 2,849; 272 x 3,382; 256 x 5,577; 240 x 7,193; 224 x 9,143; 208 x 10,742; 192 x 11,194; 176 x 8,578; 160 x 8,976; 144 x 4,758; 128 x 7,741; 112 x 8,421; 96 x 1,983; 80 x 48; 64; 32 x 65,834; 16 x 50,325
>   1.67% of the heap (50.53% cumulative)
>   3.03% of unreported (91.64% cumulative)
>   Allocated at {
>     #01: nsHtml5TreeBuilder::appendCharacters (c:\dev\mozilla-central\parser\html\nshtml5treebuildercppsupplement.h:573)
>     #02: nsHtml5TreeBuilder::flushCharacters (c:\dev\mozilla-central\parser\html\nshtml5treebuilder.cpp:4264)
>     #03: nsHtml5TreeBuilder::endTag (c:\dev\mozilla-central\parser\html\nshtml5treebuilder.cpp:2218)
>     #04: nsHtml5Tokenizer::emitCurrentTagToken (c:\dev\mozilla-central\parser\html\nshtml5tokenizer.cpp:296)
>     #05: nsHtml5Tokenizer::stateLoop<nsHtml5SilentPolicy> (c:\dev\mozilla-central\parser\html\nshtml5tokenizer.cpp:856)
>     #06: nsHtml5Tokenizer::tokenizeBuffer (c:\dev\mozilla-central\parser\html\nshtml5tokenizer.cpp:405)
>     #07: nsHtml5StreamParser::ParseAvailableData (c:\dev\mozilla-central\parser\html\nshtml5streamparser.cpp:1415)
>     #08: nsHtml5StreamParser::DoDataAvailable (c:\dev\mozilla-central\parser\html\nshtml5streamparser.cpp:1113)
>     #09: nsHtml5StreamParser::CopySegmentsToParser (c:\dev\mozilla-central\parser\html\nshtml5streamparser.cpp:1207)
>     #10: nsStringInputStream::ReadSegments (c:\dev\mozilla-central\xpcom\io\nsstringstream.cpp:249)
>     #11: nsHtml5StreamParser::OnDataAvailable (c:\dev\mozilla-central\parser\html\nshtml5streamparser.cpp:1187)
>     #12: nsDocumentOpenInfo::OnDataAvailable (c:\dev\mozilla-central\uriloader\base\nsuriloader.cpp:305)
>     #13: mozilla::net::nsHTTPCompressConv::do_OnDataAvailable (c:\dev\mozilla-central\netwerk\streamconv\converters\nshttpcompressconv.cpp:497)
>     #14: mozilla::net::nsHTTPCompressConv::OnDataAvailable (c:\dev\mozilla-central\netwerk\streamconv\converters\nshttpcompressconv.cpp:418)
>     #15: mozilla::net::nsHttpChannel::OnDataAvailable (c:\dev\mozilla-central\netwerk\protocol\http\nshttpchannel.cpp:6699)
>     #16: nsInputStreamPump::OnStateTransfer (c:\dev\mozilla-central\netwerk\base\nsinputstreampump.cpp:603)
>     #17: nsInputStreamPump::OnInputStreamReady (c:\dev\mozilla-central\netwerk\base\nsinputstreampump.cpp:430)
>     #18: nsOutputStreamReadyEvent::Run (c:\dev\mozilla-central\xpcom\io\nsstreamutils.cpp:97)
>     #19: nsThread::ProcessNextEvent (c:\dev\mozilla-central\xpcom\threads\nsthread.cpp:1058)
>     #20: NS_ProcessNextEvent (c:\dev\mozilla-central\xpcom\glue\nsthreadutils.cpp:290)
>     #21: mozilla::ipc::MessagePumpForNonMainThreads::Run (c:\dev\mozilla-central\ipc\glue\messagepump.cpp:338)
>     #22: MessageLoop::RunHandler (c:\dev\mozilla-central\ipc\chromium\src\base\message_loop.cc:226)
>     #23: MessageLoop::Run (c:\dev\mozilla-central\ipc\chromium\src\base\message_loop.cc:206)
>     #24: nsThread::ThreadFunc (c:\dev\mozilla-central\xpcom\threads\nsthread.cpp:461)
>   }
> }

[1] https://dxr.mozilla.org/mozilla-central/rev/cf06fbc831754e54c6abb71d3136597488a530e0/parser/html/nsHtml5TreeOpStage.cpp#31
Flags: needinfo?(erahm)
(In reply to Timothy Nikkel (:tnikkel) from comment #3)
> It's weird that you got heap-unclassified, I got lots of memory being used
> in layout in my memory report. This looks like a gigantic page. Do other
> browsers do better than us on this page?

IE 11 freezes up after allocating ~1.6GB of memory. Chrome 54 eventually OOM'd the tab, but it's multiprocess so everything else was okay.
Priority: -- → P3
Severity: minor → S4

We stopped doing alerts and started using a notification bar, and we have e10s and fission now, so I suspect this can be closed. If this is still an issue we should file a new bug with newer memory/DMD reports and/or performance profiles.

Status: UNCONFIRMED → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: