Closed Bug 385715 Opened 14 years ago Closed 14 years ago

ReadAV from formatblock with memory corruption evidence


(Core :: DOM: Editor, defect)

Windows XP
Not set





(Reporter: pvnick, Assigned: peterv)



(Keywords: assertion, fixed1.8.1.5, verified1.8.0.13, Whiteboard: [sg:critical?] fixed by bug 382778)


(2 obsolete files)

Attached file 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]	

Sorry I couldn't provide more information. This doesn't seem crash on my Linux box, which is what I use for debugging Firefox.
Flags: blocking1.8.1.5?
Flags: blocking1.8.0.13?
Attached file unreduced testcase (obsolete) —
attached to show the unpredictability of the bug. notice how eip becomes essentially random.
Attached file fuss.js - needed by unreduced testcase (obsolete) —
Attached file unreduced testcase
reattached as zip since bugzilla doesnt preserve attachment filenames
Attachment #269640 - Attachment is obsolete: true
Attachment #269642 - Attachment is obsolete: true
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:


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)
Component: DOM → Editor
QA Contact: general → editor
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
Keywords: assertion
Patch in bug 382778 should fix this one too.
Depends on: 382778
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)
Assignee: nobody → peterv
Flags: wanted1.8.1.x+
Flags: wanted1.8.0.x+
Flags: blocking1.9?
Putting on blocking list unless we learn this is not a branch problem
Flags: blocking1.8.1.5?
Flags: blocking1.8.1.5+
Flags: blocking1.8.0.13?
Flags: blocking1.8.0.13+
Whiteboard: [sg:critical?] uninitialized mem on branch?
Do we need a separate 1.8 branch patch for this one, or will back-porting bug 382778 do the trick?
Flags: blocking1.9? → blocking1.9+
bug 382778 is fixed on trunk and landed on 1.8 branches
Closed: 14 years ago
Resolution: --- → FIXED
Verification of this for is difficult. The reduced case cannot be accessed via Thunder Browse (the only 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.
verified fixed using the testcase in this bug - no crash on Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv: Gecko/20070822 Firefox/

Adding verified keyword
Whiteboard: [sg:critical?] uninitialized mem on branch? → [sg:critical?] fixed by bug 382778
Group: security
Flags: in-testsuite?
You need to log in before you can comment on or make changes to this bug.