385715 - ReadAV from formatblock with memory corruption evidence

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Paul Nickerson]

Attachment: reduced testcase

0079E2A7  mov         eax,dword ptr [ecx+0Ch] 
0079E2AA  test        eax,eax 
0079E2AC  mov         dword ptr [edx],eax 
0079E2AE  je          0079E2B6 
0079E2B0  mov         ecx,dword ptr [eax] 
0079E2B2  push        eax  
0079E2B3  call        dword ptr [ecx+4]    <---- crashes here


 	00000236()   <---- this seems to be random before reduction
>	firefox.exe!0079e2b6() 	
 	[Frames below may be incorrect and/or missing, no symbols loaded for firefox.exe]	
 	firefox.exe!0079c220() 	
 	firefox.exe!0080e4b1() 	
 	firefox.exe!00787b02() 	
 	firefox.exe!00787d44() 	


Sorry I couldn't provide more information. This doesn't seem crash on my Linux box, which is what I use for debugging Firefox.

Comment 1

[Paul Nickerson]

Attachment: unreduced testcase

attached to show the unpredictability of the bug. notice how eip becomes essentially random.

Comment 2

[Paul Nickerson]

Attachment: basic.css - needed by unreduced testcase

Comment 3

[Paul Nickerson]

Attachment: imported.css - needed by unreduced testcase

Comment 4

[Paul Nickerson]

Attachment: fuss.js - needed by unreduced testcase

Comment 5

[Paul Nickerson]

Attachment: fuzzer-combined-dm.js - needed by unreduced testcase

Comment 6

[Paul Nickerson]

Attachment: unreduced testcase

reattached as zip since bugzilla doesnt preserve attachment filenames

Comment 7

[Jeff Walden [:Waldo]]

Note for the future: if you put all the files for a testcase in a zip and use only relative hyperlinks, as though the files weren't inside a zip but rather were inside a single directory, you can just upload the zip and point to a single URL within the zip, using a jar: URL (not cross-browser, but works in Moz-based stuff).  For example, using the zip you posted:

jar:https://bugzilla.mozilla.org/attachment.cgi?id=269645!/testcase.htm


Here's most of a Mac stacktrace.  It's crashing on the NS_IF_RELEASE in nsEditor::InsertNode:


Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_INVALID_ADDRESS (0x0001) at 0x5590c3d1

Thread 0 Crashed:
0   libgklayout.dylib        	0x1815c1ed nsEditor::InsertNode(nsIDOMNode*, nsIDOMNode*, int) + 247 (nsEditor.cpp:1435)
1   libgklayout.dylib        	0x18163c68 nsEditor::ReplaceContainer(nsIDOMNode*, nsCOMPtr<nsIDOMNode>*, nsAString_internal const&, nsAString_internal const*, nsAString_internal const*, int) + 1022 (nsEditor.cpp:1613)
2   libgklayout.dylib        	0x182e1e8a nsHTMLEditRules::ApplyBlockStyle(nsCOMArray<nsIDOMNode>&, nsAString_internal const*) + 640 (nsHTMLEditRules.cpp:6867)
3   libgklayout.dylib        	0x182e7a38 nsHTMLEditRules::WillMakeBasicBlock(nsISelection*, nsAString_internal const*, int*, int*) + 2600 (nsHTMLEditRules.cpp:3400)
4   libgklayout.dylib        	0x182f250a nsHTMLEditRules::WillDoAction(nsISelection*, nsRulesInfo*, int*, int*) + 932 (nsHTMLEditRules.cpp:619)
5   libgklayout.dylib        	0x182b676a nsHTMLEditor::InsertBasicBlock(nsAString_internal const&) + 334 (nsHTMLEditor.cpp:2711)
6   libgklayout.dylib        	0x182b6eb6 nsHTMLEditor::SetParagraphFormat(nsAString_internal const&) + 190 (nsHTMLEditor.cpp:2178)
7   libcomposer.dylib        	0x3d48baa9 nsParagraphStateCommand::SetState(nsIEditor*, nsString&) + 161 (nsComposerCommands.cpp:725)
8   libcomposer.dylib        	0x3d48a55c nsMultiStateCommand::DoCommandParams(char const*, nsICommandParams*, nsISupports*) + 324 (nsComposerCommands.cpp:666)
9   libembedcomponents.dylib 	0x16cd9270 nsControllerCommandTable::DoCommandParams(char const*, nsICommandParams*, nsISupports*) + 222 (nsControllerCommandTable.cpp:208)
10  libembedcomponents.dylib 	0x16cd4774 nsBaseCommandController::DoCommandWithParams(char const*, nsICommandParams*) + 324 (nsBaseCommandController.cpp:185)
11  libembedcomponents.dylib 	0x16cd74e2 nsCommandManager::DoCommand(char const*, nsICommandParams*, nsIDOMWindow*) + 242 (nsCommandManager.cpp:270)
12  libgklayout.dylib        	0x18018c01 nsHTMLDocument::ExecCommand(nsAString_internal const&, int, nsAString_internal const&, int*) + 1293 (nsHTMLDocument.cpp:4129)
13  libxpcom_core.dylib      	0x0136c762 NS_InvokeByIndex_P + 98 (xptcinvoke_unixish_x86.cpp:179)
14  libxpconnect.dylib       	0x12a43d3c XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) + 4832 (xpcwrappednative.cpp:2229)
15  libxpconnect.dylib       	0x12a4b7d4 XPC_WN_CallMethod(JSContext*, JSObject*, unsigned, long*, long*) + 398 (xpcwrappednativejsops.cpp:1467)
16  libmozjs.dylib           	0x0105eb4b js_Invoke + 2768 (jsinterp.c:1306)
17  libmozjs.dylib           	0x0106ff81 js_Interpret + 64306 (jsinterp.c:3992)
18  libmozjs.dylib           	0x0105ebd6 js_Invoke + 2907 (jsinterp.c:1325)
19  libmozjs.dylib           	0x0105ef6c js_InternalInvoke + 309 (jsinterp.c:1400)
20  libmozjs.dylib           	0x0101e048 JS_CallFunctionValue + 60 (jsapi.c:4855)
21  libgklayout.dylib        	0x180e6bd6 nsJSContext::CallEventHandler(nsISupports*, void*, void*, nsIArray*, nsIVariant**) + 1228 (nsJSEnvironment.cpp:1825)
22  libgklayout.dylib        	0x1810a2fc nsGlobalWindow::RunTimeout(nsTimeout*) + 1778 (nsGlobalWindow.cpp:6857)

Comment 8

[Jeff Walden [:Waldo]]

This triggers the following assertion twice:

###!!! ASSERTION: bad action nesting!: 'mActionNesting>0', file /Users/jwalden/moz/trunk/mozilla/editor/libeditor/html/nsHTMLEditRules.cpp, line 385

...followed by a few screenfuls of the following warning, and then the crash:

WARNING: NS_ENSURE_TRUE(newRoot) failed: file /Users/jwalden/moz/trunk/mozilla/content/base/src/nsRange.cpp, line 738

Comment 9

[Olli Pettay [:smaug][[e-mail]]]

Patch in bug 382778 should fix this one too.

Comment 10

[Daniel Veditz [:dveditz]]

I don't crash on the branch with bug 382778, but the branch crashes on this one. In a debug build I appear to have gotten an uninitialized (0xcccccccc) address for txn in nsEditor::InsertNode

However, if bug 382778 is a potential fix I'll assign this to the same assignee (peterv)

Comment 11

[Daniel Veditz [:dveditz]]

Putting on blocking list unless we learn this is not a branch problem

Comment 12

[Daniel Veditz [:dveditz]]

Do we need a separate 1.8 branch patch for this one, or will back-porting bug 382778 do the trick?

Comment 13

[Daniel Veditz [:dveditz]]

bug 382778 is fixed on trunk and landed on 1.8 branches

Comment 14

[Al Billings [:abillings - ex-MoCo]]

Verification of this for 1.5.0.13 is difficult. The reduced case cannot be accessed via Thunder Browse (the only 1.5.0.13 vehicle is Thunderbird) and the unreduced case is huge and doesn't seem to do anything. Because the reduced test case was attached as an html file, it is nearly impossible to save it off and preserve it.

Comment 15

[Carsten Book [:Tomcat]]

verified fixed 1.8.0.13 using the testcase in this bug - no crash on Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.8.0.13pre) Gecko/20070822 Firefox/1.5.0.13pre

Adding verified keyword