Closed Bug 858791 Opened 11 years ago Closed 5 years ago

crash in nsTextEditorState::GetValue with abort message: "OOM: file e:/builds/.../xpcom/string/src/nsReadableUtils.cpp, line 158"

Categories

(Core :: DOM: Editor, defect)

20 Branch
x86
Windows XP
defect
Not set
critical

Tracking

()

RESOLVED WORKSFORME
Tracking Status
firefox20 --- affected
firefox22 --- affected
firefox23 --- affected

People

(Reporter: scoobidiver, Unassigned)

References

Details

(Keywords: crash, regression, Whiteboard: [startupcrash])

Crash Data

It's currently #82 browser crasher in 20.0.
It started spiking in 20.0b5. The regression range is:
http://hg.mozilla.org/releases/mozilla-beta/pushloghtml?fromchange=a853b233420d&tochange=163304f85fc1
It's likely a regression from bug 836263.

Signature 	mozalloc_abort(char const* const) | NS_DebugBreak_P | nsTextEditorState::GetValue(nsAString_internal&, bool) More Reports Search
UUID	c0bacfc4-06da-4194-8a1a-2b48e2130405
Date Processed	2013-04-05 18:48:45
Uptime	24
Last Crash	1.5 hours before submission
Install Age	2.2 days since version was first installed.
Install Time	2013-04-03 14:58:00
Product	Firefox
Version	20.0
Build ID	20130326150557
Release Channel	release
OS	Windows NT
OS Version	6.1.7601 Service Pack 1
Build Architecture	x86
Build Architecture Info	GenuineIntel family 6 model 23 stepping 10
Crash Reason	EXCEPTION_BREAKPOINT
Crash Address	0x72ad1995
App Notes 	
AdapterVendorID: 0x1002, AdapterDeviceID: 0x68b8, AdapterSubsysID: 29901682, AdapterDriverVersion: 8.791.0.0
D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ xpcom_runtime_abort(###!!! ABORT: OOM: file e:/builds/moz2_slave/rel-m-rel-w32_bld-000000000000/build/xpcom/string/src/nsReadableUtils.cpp, line 158)
Processor Notes 	sp-processor04.phx1.mozilla.com_21124:2008
EMCheckCompatibility	True
Adapter Vendor ID	0x1002
Adapter Device ID	0x68b8
Total Virtual Memory	2147352576
Available Virtual Memory	759205888
System Memory Use Percentage	64
Available Page File	4144070656
Available Physical Memory	1240862720

Frame 	Module 	Signature 	Source
0 	mozalloc.dll 	mozalloc_abort 	memory/mozalloc/mozalloc_abort.cpp:30
1 	xul.dll 	NS_DebugBreak_P 	xpcom/base/nsDebugImpl.cpp:379
2 	xul.dll 	nsTextEditorState::GetValue 	content/html/content/src/nsTextEditorState.cpp:1753
3 	xul.dll 	nsHTMLInputElement::GetValueInternal 	content/html/content/src/nsHTMLInputElement.cpp:1011
4 	xul.dll 	nsHTMLInputElement::GetValue 	content/html/content/src/nsHTMLInputElement.cpp:996
5 	xul.dll 	nsIDOMHTMLInputElement_GetValue 	obj-firefox/js/xpconnect/src/dom_quickstubs.cpp:5215
6 	mozjs.dll 	JSObject::getGeneric 	js/src/jsobjinlines.h:174
7 	mozjs.dll 	proxy_GetGeneric 	js/src/jsproxy.cpp:2615
8 	mozjs.dll 	JSObject::getGeneric 	js/src/jsobjinlines.h:171
9 	mozjs.dll 	js::GetPropertyOperation 	js/src/jsinterpinlines.h:287
10 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:2233
11 	mozjs.dll 	js::RunScript 	js/src/jsinterp.cpp:338
12 	mozjs.dll 	JSScript::makeAnalysis 	js/src/jsinfer.cpp:5588
13 	mozjs.dll 	js::ContextStack::ensureOnTop 	js/src/vm/Stack.cpp:970
14 	xul.dll 	XPC_WN_NoHelper_Resolve 	js/xpconnect/src/XPCWrappedNativeJSOps.cpp:692
15 	mozjs.dll 	proxy_Call 	js/src/jsproxy.cpp:2996
16 	mozjs.dll 	js::InvokeKernel 	js/src/jsinterp.cpp:382
17 	mozjs.dll 	js::Interpret 	js/src/jsinterp.cpp:2366
...

More reports at:
https://crash-stats.mozilla.com/report/list?signature=mozalloc_abort%28char+const*+const%29+|+NS_DebugBreak_P+|+nsTextEditorState%3A%3AGetValue%28nsAString_internal%26%2C+bool%29
It's likely that bug 836263 changed the signature here, but it's pretty unlikely that it actually changed the volume. This was probably originally attributed to a UTF8toUTF16 signature (NS_ConvertUTF8toUTF16 or AppendUTF8toUTF16).

The low uptime here is surprising, and indicates that we're probably setting a input with large text from session restore.

Ehsan, do you know if there's a way to make this more fallible without totally screwing up the text editor?
Flags: needinfo?(ehsan)
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> It's likely that bug 836263 changed the signature here, but it's pretty
> unlikely that it actually changed the volume. This was probably originally
> attributed to a UTF8toUTF16 signature (NS_ConvertUTF8toUTF16 or
> AppendUTF8toUTF16).
Maybe the volume of both is the same but this one is not correlated to Crossrider extensions so new users have been affected.
Or it would explain why that bug had only moderate correlations, because it is in fact several different bugs under one signature (and it isn't helped by the stackwalking being very imperfect).
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #1)
> Ehsan, do you know if there's a way to make this more fallible without
> totally screwing up the text editor?

I don't think that is easily possible.  But are we really dealing with such big allocations here?
Flags: needinfo?(ehsan)
Sorry, what I meant to ask here was: are we really dealing with such big allocations coming from content here?
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsTextEditorState::GetValue(nsAString_internal&, bool)] → [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsTextEditorState::GetValue(nsAString_internal&, bool)] [@ mozalloc_abort(char const* const) | NS_DebugBreak ]
Depends on: 858926
Keywords: needURLs
OS: Windows 7 → Windows XP
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsTextEditorState::GetValue(nsAString_internal&, bool)] [@ mozalloc_abort(char const* const) | NS_DebugBreak ] → [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsTextEditorState::GetValue(nsAString_internal&, bool)] [@ mozalloc_abort(char const* const) | NS_DebugBreak]
187 	about:sessionrestore
8 	about:blank
4 	about:newtab
3 	http://getfoxyproxy.org/mozilla/standard/install.html

there are also a couple dozen single hits on various pages

perhaps a crash on restart after a previous crash?
Keywords: needURLs
Crash Signature: [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsTextEditorState::GetValue(nsAString_internal&, bool)] [@ mozalloc_abort(char const* const) | NS_DebugBreak] → [@ mozalloc_abort(char const* const) | NS_DebugBreak_P | nsTextEditorState::GetValue(nsAString_internal&, bool)] [@ mozalloc_abort(char const* const) | NS_DebugBreak] [@ mozalloc_abort(char const* const) | NS_DebugBreak | nsTextEditorState::GetValue(nsA…
(In reply to Tracy Walker [:tracy] from comment #6)
> perhaps a crash on restart after a previous crash?


I just had two crashes, both have this signature.  My last crash bp-787b30d8-7f98-45ed-9423-9e6ee2130809 was after startup. My first crash bp-b16bb0c2-0edd-41ba-a490-f5b6c2130809 was not after startup.

sessionstore.js is 24MB, which might be a factor.  I have terrible jank and iGC times
(In reply to Wayne Mery (:wsmwk) from comment #7)
> (In reply to Tracy Walker [:tracy] from comment #6)
> > perhaps a crash on restart after a previous crash?
> 
> 
> I just had two crashes, both have this signature.  My last crash
> [1] bp-787b30d8-7f98-45ed-9423-9e6ee2130809 was after startup. My first crash
> [2] bp-b16bb0c2-0edd-41ba-a490-f5b6c2130809 was not after startup.

correction - signature are not the same
[1] mozalloc_abort(char const* const) | NS_DebugBreak | nsTextEditorState::GetValue(nsAString_internal&, bool) 
[2] mozalloc_abort(char const* const) | NS_DebugBreak | mozilla::dom::HTMLInputElement::SetValueInternal(nsAString_internal const&, bool, bool)
https://crash-stats.mozilla.com/report/index/6b9afe4f-93ce-45ad-b715-ca5c42131122
This report crashed after 24 seconds of uptime on about:sessionrestore. The system has a 241MB VA block available. How did this fail? Are the strings really that huge?
Possibly yes. Once bug 938794 lands somewhere useful we'll know a lot more. But it's not entirely impossible to imagine a giant sessionstore file with very large restored input values. We should probably cap the size of the values we store, though.
(In reply to comment #10)
> Possibly yes. Once bug 938794 lands somewhere useful we'll know a lot more. But
> it's not entirely impossible to imagine a giant sessionstore file with very
> large restored input values. We should probably cap the size of the values we
> store, though.

Or not save huge values in the first place.
My sessionstore file is now 115.105.837 bytes which is ~109MB.
When I was using firefox 24, sessionstore.js was ~70MB. What changed? The only thing I changed was the firefox version, nothing else.

What can be the cause?
https://crash-stats.mozilla.com/report/index/bp-77375857-e352-46ec-bef9-702ad2131126
https://crash-stats.mozilla.com/report/index/bp-a331add2-bd00-4b39-8547-0fa262131126
https://crash-stats.mozilla.com/report/index/bp-14b81feb-67a5-40a7-9457-7d6192131126
https://crash-stats.mozilla.com/report/index/bp-aa605064-fcf3-4e85-a772-157362131126
https://crash-stats.mozilla.com/report/index/bp-bf842c9a-ac2a-4f19-af82-5bde92131126
https://crash-stats.mozilla.com/report/index/bp-c83babe6-b761-4fbb-945a-b036d2131126
https://crash-stats.mozilla.com/report/index/bp-1258f37f-2ecc-4a4e-b4a2-525f62131126
https://crash-stats.mozilla.com/report/index/bp-6560e557-d07f-455d-8908-519d72131126
https://crash-stats.mozilla.com/report/index/bp-5b811c56-b79f-49ba-a019-c82342131126
https://crash-stats.mozilla.com/report/index/bp-c0149d7a-de50-4b91-9705-68b9b2131126
https://crash-stats.mozilla.com/report/index/bp-a06131ae-9d67-4f85-bd1a-f61f92131126
https://crash-stats.mozilla.com/report/index/bp-24597e59-e555-4baa-9adf-431e02131126
https://crash-stats.mozilla.com/report/index/bp-71dcc536-984e-4ca4-8baf-3321a2131126
https://crash-stats.mozilla.com/report/index/bp-1c66de26-7158-424e-af3f-6aa512131126
https://crash-stats.mozilla.com/report/index/bp-8a1eb977-1991-4682-8018-fd6522131126

These were today's crashes.


Some of them are related to this bug. Most of them show that this bug is related with the situation of the crash. I didn't place here only those, I pasted all and the ones that include the ones that point here.

 If you need me to paste here more crash signature, just needinfo me.
Flags: needinfo?(ehsan)
Just found a very interesting fact.
My sessionstore.js is ~100MB and contains a whole lot of gibberish data. A small search I made says that that jibberish data is data stored using the sessionstore.

Could it be that that data is participating in generating these crashes I've (and others) been experiencing?
I don't know what it is exactly, but what you see as "gibberish" could just be encoded in some form. That said, this large sessionstore.js is very likely to be behind your problems.

I think there is a rewrite of the session store being worked on, but I wonder if it might be helpful for a developer to look into this large session store (though handing it over might not be what you want to do as there can be any number of private info in it, depending on what's in this session).
Not sure what information you've requested from me.
Flags: needinfo?(ehsan)
Crash Signature: , bool)] [@ mozalloc_abort(char const* const) | NS_DebugBreak] [@ mozalloc_abort(char const* const) | NS_DebugBreak | nsTextEditorState::GetValue(nsAString_internal&, bool) ] → , bool)] [@ mozalloc_abort(char const* const) | NS_DebugBreak] [@ mozalloc_abort(char const* const) | NS_DebugBreak | nsTextEditorState::GetValue(nsAString_internal&, bool) ] [@ mozalloc_abort | NS_DebugBreak_P | nsTextEditorState::GetValue] [@ mozall…

Closing because no crashes reported for 12 weeks.

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