Large OOM in nsTextFragment::AppendTo

RESOLVED DUPLICATE of bug 950076

Status

()

Core
String
--
critical
RESOLVED DUPLICATE of bug 950076
4 years ago
4 years ago

People

(Reporter: Robert Kaiser, Unassigned)

Tracking

({crash})

26 Branch
x86
Windows NT
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

(Reporter)

Description

4 years ago
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.

Comment 1

4 years ago
Already fixed in 31.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 950076

Comment 2

4 years ago
Please reopen, I can reproduce it in Firefox 31, with this report id: bp-48da154b-a650-45a0-975e-3cbc72140821
You need to log in before you can comment on or make changes to this bug.