Closed Bug 573078 Opened 9 years ago Closed 8 years ago

[Mac] OOM in nsHtml5StreamParser::WriteStreamBytes [@ mozalloc_abort(char const*) ]

Categories

(Core :: HTML: Parser, defect, P4, critical)

Product:
Core
Component:
HTML: Parser
Platform:
All
macOS
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla10

People

(Reporter: marcia, Assigned: hsivonen)

References

Details

(Keywords: crash, topcrash, Whiteboard: [inbound])

Crash Data

Seen while reviewing trunk crash stats. Now the #14 overall top crash on trunk and #1 top crash on Mac.

http://tinyurl.com/25q7vnm links to all current crashes. It appears the crashes started on 6/11 and then spiked on 6/17.

Not many URLs to go on as many of the crashes happened right after startup. I contacted on mozilla person who crashed and he said he had no idea how it happened.
Frame  	Module  	Signature [Expand]  	Source
0 	libmozalloc.dylib 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:64
1 	libmozalloc.dylib 	mozalloc_handle_oom 	memory/mozalloc/mozalloc_oom.cpp:54
2 	libmozalloc.dylib 	libmozalloc.dylib@0xcc0 	
3 	XUL 	XUL@0x62bad6 	
4 	XUL 	nsHtml5StreamParser::WriteStreamBytes 	parser/html/nsHtml5StreamParser.cpp:513
5 	XUL 	nsHtml5StreamParser::DoDataAvailable 	parser/html/nsHtml5StreamParser.cpp:665
6 	XUL 	nsHtml5DataAvailable::Run 	parser/html/nsHtml5StreamParser.cpp:705
7 	XUL 	nsThread::ProcessNextEvent 	xpcom/threads/nsThread.cpp:547
8 	XUL 	NS_ProcessNextEvent_P 	nsThreadUtils.cpp:250
9 	XUL 	nsThread::ThreadFunc 	xpcom/threads/nsThread.cpp:263
10 	libnspr4.dylib 	_pt_root 	nsprpub/pr/src/pthreads/ptthread.c:228
11 	libSystem.B.dylib 	_pthread_start 	
12 	libSystem.B.dylib 	thread_start
Approaching the 500 crash mark, which is a high for a Mac nightly. http://tinyurl.com/2fasce3 links to the crashes, which are mostly startup crashes.

Comments mention:

trying to start minefield while firefox is running
I'm just trying to start up.

https://crash-stats.mozilla.com/report/index/280ac94b-a672-4af2-b526-6ce992100622 is interesting in that a line in that stack indicates: _ZL20ProfileMissingDialogP19nsINativeAppSupport
Keywords: topcrash
These crashes don't show up when you filter on the "1.9.3 branch" -- as I've been used to doing for the last few months.  So I completely missed them.

Wierd!
I don't know how to categorize this bug report.
OS: Mac OS X → All
Hardware: x86 → All
This stack from comment 1 signifies OOM in the HTML5 parser.  If that stack starts moving up the topcrash leaderboard, the allocating code here needs to switch to explicitly fallible allocation.
Component: General → HTML: Parser
QA Contact: general → parser
Actually, these *are* Mac-specific.

I've seen reports for OS X 10.5.8 and various versions of 10.6.X.
OS: All → Mac OS X
The number of these crashes over the last two weeks (460) is truly dramatic.  The next legitimate entry in the Mac topcrasher list (js_UnboxDouble(long)) has only 8 crashes!  (The crashes at nsCrasher::Crash(short) are in the "crashme" testing extension.)

http://crash-stats.mozilla.com/query/query?product=Firefox&version=Firefox%3A3.7a6pre&platform=mac&range_value=2&range_unit=weeks&date=06%2F23%2F2010+12%3A52%3A43&query_search=signature&query_type=exact&query=&build_id=&process_type=any&hang_type=any&do_query=1
Fortunately A5 (based on the 2010-06-10 nightly) doesn't have any of these crashes.
From a random sampling of the reports in comment 8, it appears to me that the majority are

0  	libmozalloc.dylib  	mozalloc_abort  	 memory/mozalloc/mozalloc_abort.cpp:64
1 	XUL 	NS_DebugBreak_P 	xpcom/base/nsDebugImpl.cpp:379
2 	XUL 	XUL@0xc8185c 	
3 	XUL 	base::ThreadLocalPlatform::SetValueInSlot 	ipc/chromium/src/base/logging.h:61
4 	XUL 	XUL@0xc83000 	
5 	XUL 	NS_InitXPCOM3_P 	ipc/chromium/src/base/message_loop.h:434
6 	XUL 	ScopedXPCOMStartup::Initialize 	toolkit/xre/nsAppRunner.cpp:1145
7 	XUL 	ProfileMissingDialog 	toolkit/xre/nsAppRunner.cpp:1901
8 	XUL 	XRE_main 	toolkit/xre/nsAppRunner.cpp:3264
9 	firefox-bin 	main 	browser/app/nsBrowserApp.cpp:158
10 	firefox-bin 	firefox-bin@0xbf5 	
11 		@0x1

I did see some crashes in the HTML5 parser that looked the same as comment 1, so I suggest we morph this bug into the OOM tracker and spin off a new bug for the startup problem.  (The OOM shouldn't be mac-specific, but one never knows ...)
Summary: [Mac] Crash in [@ mozalloc_abort(char const*) ] → [Mac] OOM in nsHtml5StreamParser::WriteStreamBytes [@ mozalloc_abort(char const*) ]
Spun off initialization problem into bug 574139.
(In reply to comment #1)
> Frame      Module      Signature [Expand]      Source
> 0     libmozalloc.dylib     mozalloc_abort    
> memory/mozalloc/mozalloc_abort.cpp:64
> 1     libmozalloc.dylib     mozalloc_handle_oom    
> memory/mozalloc/mozalloc_oom.cpp:54
> 2     libmozalloc.dylib     libmozalloc.dylib@0xcc0     
> 3     XUL     XUL@0x62bad6

I'm guessing stack frame #3 has to be the constructor for nsHtml5UTF16Buffer. I wonder why there's no symbol.

> 4     XUL     nsHtml5StreamParser::WriteStreamBytes    
> parser/html/nsHtml5StreamParser.cpp:513

Assuming that stack frame #3 is the constructor for nsHtml5UTF16Buffer, this crash is a case where the HTML5 parser allocates 1 KB at a time. Does the infallible malloc already have a mechanism for freeing stuff (killing tabs?) when it runs low on memory? If it does, is 1 KB too much to allocate at a time for the mechanism to work?

If I made the HTML5 parser return NS_ERROR_OUT_OF_MEMORY to the event loop of the parser thread, what would happen? If the next buffer were pushed to the parser nonetheless and it happened to succeed, a piece of the page would be missing, which could change the executability properties of pieces of the page.
(In reply to comment #12)
> Does the
> infallible malloc already have a mechanism for freeing stuff (killing tabs?)
> when it runs low on memory?

Apparently not:
http://mxr-test.konigsberg.mozilla.org/mozilla-central/source/memory/mozalloc/mozalloc_oom.cpp#49
:-(
What to do here really depends on whether the infallible malloc becomes able to stop active parsers or (failing that) zap existing tabs/windows to free memory.
Priority: -- → P3
We're not going to have tabs in their own process(es) until FF 5.  That gives us more OOM-handling options.  Until then, this allocation site should be made fallible and (probably) bail on OOM.

(In reply to comment #12)
> If I made the HTML5 parser return NS_ERROR_OUT_OF_MEMORY to the event loop of
> the parser thread, what would happen? If the next buffer were pushed to the
> parser nonetheless and it happened to succeed, a piece of the page would be
> missing, which could change the executability properties of pieces of the page.

I can't answer that question, but it'd be easy enough to simulate an OOM here and find out.
(In reply to comment #15)
> We're not going to have tabs in their own process(es) until FF 5.  That gives
> us more OOM-handling options.  Until then, this allocation site should be made
> fallible and (probably) bail on OOM.

OK. :-(

> (In reply to comment #12)
> > If I made the HTML5 parser return NS_ERROR_OUT_OF_MEMORY to the event loop of
> > the parser thread, what would happen? If the next buffer were pushed to the
> > parser nonetheless and it happened to succeed, a piece of the page would be
> > missing, which could change the executability properties of pieces of the page.
> 
> I can't answer that question, but it'd be easy enough to simulate an OOM here
> and find out.

It seems to me that if this allocation fails, the parser needs to be flagged broken and subsequent buffer should be ignored, too, for security reasons.
Priority: P3 → P2
Safe (as in not allowing arbitrary code execution) OOM crashes in the parser are now lower priority than Web-facing correctness fixes.
Priority: P2 → P4
Crash Signature: [@ mozalloc_abort(char const*) ]
https://hg.mozilla.org/integration/mozilla-inbound/rev/daef044609ce
Whiteboard: [inbound]
Target Milestone: --- → mozilla10
Assignee: nobody → hsivonen
Status: NEW → ASSIGNED
https://hg.mozilla.org/mozilla-central/rev/daef044609ce
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Duplicate of this bug: 636318
You need to log in before you can comment on or make changes to this bug.