Closed Bug 1027168 Opened 10 years ago Closed 10 years ago

Large OOM in nsTextFragment::AppendTo

Categories

(Core :: XPCOM, defect)

Product:
Core
Component:
XPCOM
Version:
26 Branch
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED DUPLICATE of bug 950076

People

(Reporter: kairo, Unassigned)

Details

(Keywords: crash)

Crash Data

This bug was filed from the Socorro interface and is 
report bp-4ee1c052-3949-4a7d-9648-6f2a02140616.
=============================================================

Top frames:
0 	xul.dll 	NS_ABORT_OOM(unsigned int) 	xpcom/base/nsDebugImpl.cpp
1 	xul.dll 	nsTextFragment::AppendTo(nsAString_internal &) 	content/base/src/nsTextFragment.h
2 	xul.dll 	nsContentUtils::AppendNodeTextContent(nsINode *,bool,nsAString_internal &) 	content/base/src/nsContentUtils.cpp
3 	xul.dll 	mozilla::dom::HTMLScriptElement::GetText(nsAString_internal &) 	content/html/content/src/HTMLScriptElement.cpp

Most of the OOM crashes in https://crash-stats.mozilla.com/report/list?signature=OOM%20%7C%20large%20%7C%20NS_ABORT_OOM%28unsigned%20int%29%20%7C%20nsTextFragment%3A%3AAppendTo%28nsAString_internal%26%29 are doing slightly-over-1M or ~600k allocations and coming from nsContentUtils::AppendNodeTextContent to nsTextFragment::AppendTo but some are really huge, like bp-bd4f44c1-163f-4a1e-8a0f-269f22140617 which is coming from nsBidiPresUtils::TraverseFrames and tries a >75M allocation.

We should be doing fallible instead of infallible allocation here.
Already fixed in 31.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Please reopen, I can reproduce it in Firefox 31, with this report id: bp-48da154b-a650-45a0-975e-3cbc72140821
Component: String → XPCOM
You need to log in before you can comment on or make changes to this bug.