Closed Bug 741090 Opened 12 years ago Closed 6 years ago

OOM crash in nsGenericDOMDataNode::SetTextInternal

Categories

(Core :: DOM: Core & HTML, defect)

x86
Windows 7
defect
Not set
critical

Tracking

()

RESOLVED WONTFIX

People

(Reporter: over68, Unassigned)

Details

(Keywords: crash, reproducible)

Crash Data

Mozilla/5.0 (Windows NT 6.1; rv:14.0) Gecko/20120331 Firefox/14.0a1

Crash report:
http://crash-stats.mozilla.com/report/index/bp-540b23c2-e1ba-4b91-a286-cfcbd2120331
What are your steps to reproduce?
Did it happen in the previous build, 14.0a1/20120330?
Crash Signature: [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsGenericDOMDataNode::SetTextInternal(unsigned int, unsigned int, wchar_t const*, unsigned int, bool, CharacterDataChangeInfo::Details*)]
Component: General → DOM
Keywords: crash
QA Contact: general → general
Steps to reproduce:
1. Download this file https://rapidshare.com/files/869381982/path.zip
2. Open the file path.log by the browser.
(In reply to Scoobidiver from comment #1)
> Did it happen in the previous build, 14.0a1/20120330?

Yes
I don't crash with 4GB of RAM.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Crash in @ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsGenericDOMDataNode::SetTextInternal(unsigned int, unsigned int, wchar_t const*, unsigned int, bool, CharacterDataChangeInfo::Details*) → OOM crash in nsGenericDOMDataNode::SetTextInternal
Version: 14 Branch → Trunk
(In reply to Scoobidiver from comment #4)
> I don't crash with 4GB of RAM.

Try this page http://kaubonschen.com/100000000/log/path.log

Crash report:
http://crash-stats.mozilla.com/report/index/bp-06203059-b2cb-4f28-b41f-9b4f32120331
(In reply to TB from comment #5)
> Try this page http://kaubonschen.com/100000000/log/path.log
I don't crash.

With your STR in comment 2, does it happen in Safe Mode (see http://support.mozilla.org/kb/Safe%20Mode)? with a new profile (see http://support.mozilla.org/kb/Managing-profiles)?
The signature is an out-of-memory crash, so whether you hit it will depend on lots of things (like what else you have loaded and what else your computer is doing), no?
(In reply to Boris Zbarsky (:bz) from comment #7)
> The signature is an out-of-memory crash, so whether you hit it will depend
> on lots of things (like what else you have loaded and what else your
> computer is doing), no?

No, This crash occurs before the out-of-memory.

See, just paste the link, the browser crashes
Note the "Memory usage"
http://s449.photobucket.com/albums/qq217/movh/?action=view&current=faefab73.mp4

Crash in another case
http://s449.photobucket.com/albums/qq217/movh/?action=view&current=5f94f8ce.mp4

This crash does not happen in Chrome
http://s449.photobucket.com/albums/qq217/movh/?action=view&current=af50f78d.mp4


Actual result:

Actually does not happen out-of-memory, this bug in the code.
(In reply to Scoobidiver from comment #6)
> With your STR in comment 2, does it happen in Safe Mode (see
> http://support.mozilla.org/kb/Safe%20Mode)? with a new profile (see
> http://support.mozilla.org/kb/Managing-profiles)?

Crash still occurs.
Scoobidiver, Try the STR in comment 2

After the page loads click on the button "Reload page"

Example http://s449.photobucket.com/albums/qq217/movh/?action=view&current=f8053406.mp4

Repeat this several times.
> No, This crash occurs before the out-of-memory.

The crash signature is showing that we're explicitly calling the out-of-memory handler, so it's out of memory...  Just look at the stacks from comment 9:

0 	mozalloc.dll 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:79
1 	mozalloc.dll 	mozalloc_handle_oom 	memory/mozalloc/mozalloc_oom.cpp:60
2 	mozalloc.dll 	moz_xmalloc 	memory/mozalloc/mozalloc.cpp:105
3 	xul.dll 	nsMemory::Clone 	obj-firefox/xpcom/build/nsMemory.cpp:61
4 	xul.dll 	nsTextFragment::SetTo 	

That's an out of memory cloning some text.

> Note the "Memory usage"

This doesn't update instantaneously.  It's pretty easy to run out of memory between updates.  Also note that "memory" for purposes of running out of it almost certainly means "address space", which may not be what your widget there is measuring...

> This crash does not happen in Chrome

Which also seems to use less memory in this case.

What would be interesting is looking into why we're using so much memory here....
> What would be interesting is looking into why we're using so much memory here....

There's bug 689769, in general.
FWIW, I don't receive a Crash against a recent 32-Bit Nightly on Win 7 x64 with 4GB RAM either.

I created a Cleopatra Profile for loading the URL mentioned in Comment 5: http://people.mozilla.com/~bgirard/cleopatra/?report=AMIfv95Nwlw7RiEe-irRjegRxcVwztliWmu-zfb1FiVWtEnkmy18CiGDPn3g9G1yw-oIzzcphfwfzX0wk99M6bZyUMFPT9a-bbG1p0MeVMJrRG_vbNfQXOUcJKGFqaoFeutfbdzrblKL8QB-QqLBjCqiuCOU7k6ESw

Spending Time in Harfbuzz and GFX Text Parsing if I read correctly.

Can the Reg.Range-Wanted KW be removed?
Crash Signature: [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsGenericDOMDataNode::SetTextInternal(unsigned int, unsigned int, wchar_t const*, unsigned int, bool, CharacterDataChangeInfo::Details*)] → [@ mozalloc_abort(char const* const) | mozalloc_handle_oom(unsigned int) | moz_xrealloc | nsGenericDOMDataNode::SetTextInternal(unsigned int, unsigned int, wchar_t const*, unsigned int, bool, CharacterDataChangeInfo::Details*)] [@ mozalloc_abort | mozall…
Closing because no crash reported since 12 weeks.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WONTFIX
Closing because no crash reported since 12 weeks.
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.