Closed Bug 858791 Opened 12 years ago Closed 6 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)

Product:
Core
Component:
DOM: Editor
Version:
20 Branch
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
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…
status-firefox23: --- → affected
(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: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.