318627 - crash with suspicious stack signature (0x20202020 = spaces)

Status: VERIFIED DUPLICATE of bug 318969

(Core :: JavaScript Engine, defect)

Description

[Tony Mechelynck [:tonymec]]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051130 Firefox/1.5
Build Identifier: "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051130 Firefox/1.5" build ID:2005113003

see TB12448731Q

Reproducible: Didn't try

Steps to Reproduce:

Actual Results:  
crash (Illegal instruction)

Expected Results:  
no crash

waiting for repaint after "Save Image As", see TB12448731Q

After reloading the crashed session, I noticed that the new disk file had not been created.

Comment 1

[timeless]

actually, the signature means garbage collection.

Incident ID: 12448731
Stack Signature	xpsp2res.dll + 0x202020 (0x20202020) e03d3801
Product ID	Firefox15
Build ID	2005113003
Trigger Time	2005-11-30 18:15:30.0
Platform	Win32
Operating System	Windows NT 5.1 build 2600
Module	xpsp2res.dll + (00202020)
URL visited	http://www.deviantart.com/view/25820055
User Comments	I was waiting for Firefox to repaint its window after I had clicked "Save" in a file selector for "Save image as". At the time of failure the top toolbars had been repainted, the current tab and tabs bar were still under an "empty white rectangle" where
Since Last Crash	9976 sec
Total Uptime	9976 sec
Trigger Reason	Illegal instruction
Source File, Line No.	N/A
Stack Trace 	
xpsp2res.dll + 0x202020 (0x20202020)
JS_GetPrivate  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsapi.c, line 2141]
XPC_NW_NewResolve  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/XPCNativeWrapper.cpp, line 847]
js_LookupPropertyWithFlags  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2675]
js_LookupProperty  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2580]
js_GetProperty  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsobj.c, line 2865]
js_Interpret  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 5249]
js_Invoke  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/jsinterp.c, line 1197]
nsXPCWrappedJSClass::CallMethod  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp, line 1369]
nsXPCWrappedJS::CallMethod  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp, line 462]
SharedStub  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp, line 147]
nsEventListenerManager::HandleEventSubType  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1685]
nsEventListenerManager::HandleEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventListenerManager.cpp, line 1786]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2153]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2174]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2174]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2174]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2174]
nsXULElement::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2174]
nsXULElement::HandleChromeEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/xul/content/src/nsXULElement.cpp, line 2833]
nsGlobalWindow::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/dom/src/base/nsGlobalWindow.cpp, line 1574]
nsDocument::HandleDOMEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsDocument.cpp, line 4013]
nsEventStateManager::DispatchNewEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/events/src/nsEventStateManager.cpp, line 4554]
nsDocument::DispatchEvent  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsDocument.cpp, line 4097]
nsDocument::DispatchContentLoadedEvents  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/base/src/nsDocument.cpp, line 2213]
nsHTMLDocument::EndLoad  [c:/builds/tinderbox/Fx-Mozilla1.8/WINNT_5.2_Depend/mozilla/content/html/document/src/nsHTMLDocument.cpp, line 983]

Comment 2

[Tony Mechelynck [:tonymec]]

(In reply to comment #1)
> actually, the signature means garbage collection.
[...]
To every day its bit of learning. I would have thought 0x20202020 as a "program" address meant trying to use string data (spaces) as if it'd be a program address (i.e., stack misalignment or some such).

-- User comments were truncated in Talkback incident above:

...an "empty white rectangle" where the file selector had been.

Comment 3

[Jesse Ruderman]

<Jesse_home> 0x20202020?
<word> rumour has it 0x20202020 is my object was garbage collected (failure to root)

You'd have to ask Brendan to find out why he chose 0x20202020.

Complete Talkback comment: "I was waiting for Firefox to repaint its window after I had clicked 'Save' in a file selector for 'Save image as'. At the time of failure the top toolbars had been repainted, the current tab and tabs bar were still under an 'empty white rectangle' where the file selector had been."

Is this likely to be a security hole?  I'd guess so, since memory that has been freed in garbage collection can be reused.

Comment 4

[timeless]

i believe this is bug 318969

Comment 5

[Tony Mechelynck [:tonymec]]

(In reply to comment #3)
> <Jesse_home> 0x20202020?
> <word> rumour has it 0x20202020 is my object was garbage collected (failure to
> root)
> 
> You'd have to ask Brendan to find out why he chose 0x20202020.
> 
> Complete Talkback comment: "I was waiting for Firefox to repaint its window
> after I had clicked 'Save' in a file selector for 'Save image as'. At the time
> of failure the top toolbars had been repainted, the current tab and tabs bar
> were still under an 'empty white rectangle' where the file selector had been."
> 
> Is this likely to be a security hole?  I'd guess so, since memory that has been
> freed in garbage collection can be reused.
> 

See also the bottom line in comment #0 : the "save to" file was not actually created. (IIUC the file requestor was in the process of closing, but Fx crashed before the file was created, written and closed.) After reloading Fx, trying to re-save to the exact same drive, directory and file name did not give the "File already exists. Overwrite?" popup.

Wouldn't such a crash have happened too early for a real security hole? (Just a guess.)

Comment 6

[Boris Zbarsky [:bzbarsky]]

*** This bug has been marked as a duplicate of 318969 ***

Comment 7

[Brendan Eich [:brendan]]

(In reply to comment #3)
> <Jesse_home> 0x20202020?
> <word> rumour has it 0x20202020 is my object was garbage collected (failure to
> root)
> 
> You'd have to ask Brendan to find out why he chose 0x20202020.

I didn't use that string of bytes.  Rather, GCF_FINAL moved to be 0x20, after being 0x10 for years.  Adjacent GC-things in the heap have adjacent (modulo the "split") flag bytes.  Hence the run of 0x20 for finalized thing-flags.

/be

Comment 8

[Jesse Ruderman]

*** Bug 319413 has been marked as a duplicate of this bug. ***