237823 - Crash [@ js_AllocStack - nsXPCWrappedJSClass::CallMethod] with js debugger (e.g. firebug)

Status: RESOLVED WORKSFORME

(Core :: XPConnect, defect)

Description

[timeless]

still using pre 1.7a, release like build (opt, profile)

I can run purify, on this build but it makes the world really slow

setup (one of a few variants i've now seen):
there's a js event listener on navigator which listens for a PopupWindow event.
there's a javascript debugger set to break into the js when the event reaches 
the listener.
dom has been modified to provide a relatedTarget which is the popped up window
popup blocking is not enabled (i need the window to trigger my event0
I load http://viper.haque.net/~timeless/blog/classic.example.com/firstpage/ in 
this navigator window because it does everything .. including pop up a window.

venkman breaks at the js handler.
the next step was to try to fish from event.relatedTarget to the chrome window 
containing the html window.

<Neil> timeless: iirc, you qi to ifreq, req the webnav, qi to docshell, get
the treeowner, get the root, then work back again... but that's from memory

So i did:
event.relatedTarget.QueryInterface
(Components.interfaces.nsIInterfaceRequestor).getInterface
(Components.interfaces.nsIWebNavigation).QueryInterface
(Components.interfaces.nsIDocShell)
that worked. problem was, i didn't remember what the tree owner property/getter 
was.

now in the current scope there were two locals, one was an uninited |index| 
(value: void). so I decided to be clever, i assigned the result of the QI/GI 
maze into index.

Nothing happened in venkman's local window view, so I tried to collapse the 
scope item hoping that reexpanding it would give me a better result.
Either the collapse or the expand (sorry, some details just aren't memorable) 
triggered this crash:

>	js3250.dll!js_AllocStack(JSContext * cx=0x00dfbcf8, unsigned int 
nslots=0x00000002, void * * markp=0x0012f024)  Line 386	C
 	xpc3250.dll!nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS * 
wrapper=0x011ead86, unsigned short methodIndex=0xc4b8, const nsXPTMethodInfo * 
info=0x01419e10, nsXPTCMiniVariant * nativeParams=0x00000000)  Line 1133 + 0x18
	C++
 	xpc3250.dll!nsXPCWrappedJS::CallMethod(unsigned short 
methodIndex=0x000d, const nsXPTMethodInfo * info=0x00e7a040, nsXPTCMiniVariant 
* params=0x0012f0c8)  Line 450	C++
 	xpcom.dll!PrepareAndDispatch(nsXPTCStubBase * self=0x00000000, unsigned 
int methodIndex=0x0000000d, unsigned int * args=0x0012f180, unsigned int * 
stackBytesToPop=0x0012f170)  Line 117 + 0x12	C++
 	xpcom.dll!SharedStub()  Line 147	C++
 	gklayout.dll!nsTreeBodyFrame::PrefillPropertyArray(int 
aRowIndex=0xffffffff, nsTreeColumn * aCol=0x03e53b50)  Line 1787	C++
 	gklayout.dll!nsTreeBodyFrame::PaintColumn(nsTreeColumn * 
aColumn=0x0012f00c, const nsRect & aColumnRect={...}, nsIPresContext * 
aPresContext=0x02b3c4b8, nsIRenderingContext & aRenderingContext={...}, const 
nsRect & aDirtyRect={...})  Line 2236	C++
 	gklayout.dll!nsTreeBodyFrame::Paint(nsIPresContext * 
aPresContext=0x02b3c4b8, nsIRenderingContext & aRenderingContext={...}, const 
nsRect & aDirtyRect={...}, nsFramePaintLayer 
aWhichLayer=eFramePaintLayer_Overlay, unsigned int aFlags=0x00000000)  Line 2182
	C++
 	gklayout.dll!PresShell::Paint(nsIView * aView=0x02e87898, 
nsIRenderingContext & aRenderingContext={...}, const nsRect & aDirtyRect=
{...})  Line 5625	C++
 	gklayout.dll!nsView::Paint(nsIRenderingContext & rc={...}, const nsRect 
& rect={...}, unsigned int aPaintFlags=0x00000000, int & aResult=0x04334e58)  
Line 262	C++
 	gklayout.dll!nsViewManager::RenderDisplayListElement
(DisplayListElement2 * element=0x04334e58, nsIRenderingContext * 
aRC=0x03d3b458)  Line 1391	C++
 	gklayout.dll!nsViewManager::RenderViews(nsView * aRootView=0x011ead86, 
nsIRenderingContext & aRC={...}, const nsRegion & aRegion={...}, void * 
aRCSurface=0x00000000)  Line 1309	C++
 	gklayout.dll!nsViewManager::Refresh(nsView * aView=0x011ead86, 
nsIRenderingContext * aContext=0x02b3c4b8, nsIRegion * aRegion=0x01419e10, 
unsigned int aUpdateFlags=0x00000000)  Line 874	C++
 	gklayout.dll!nsViewManager::DispatchEvent(nsGUIEvent * 
aEvent=0x02e87898, nsEventStatus * aStatus=0x0432fc98)  Line 1859	C++
 	gklayout.dll!HandleEvent(nsGUIEvent * aEvent=0x0012f660)  Line 79
	C++
 	gkwidget.dll!nsWindow::DispatchEvent(nsGUIEvent * event=0x0012f660, 
nsEventStatus & aStatus=nsEventStatus_eIgnore)  Line 1064 + 0x3	C++
 	gkwidget.dll!nsWindow::DispatchWindowEvent(nsGUIEvent * 
event=0x0012f660, nsEventStatus & aStatus=nsEventStatus_eIgnore)  Line 1090
	C++
 	gkwidget.dll!nsWindow::OnPaint(HDC__ * aDC=0x00000000)  Line 5001
	C++
 	gkwidget.dll!nsWindow::ProcessMessage(unsigned int msg=0x011ead86, 
unsigned int wParam=0x02b3c4b8, long lParam=0x01419e10, long * 
aRetValue=0x00000000)  Line 3781	C++
 	gkwidget.dll!nsWindow::WindowProc(HWND__ * hWnd=0x00200624, unsigned 
int msg=0x00000000, unsigned int wParam=0x00000000, long lParam=0x03e618f4)  
Line 1346 + 0x10	C++
 	user32.dll!77d43a50() 	
 	user32.dll!77d43b1f() 	
 	user32.dll!PostMessageA()  + 0xad	
 	user32.dll!PostMessageA()  + 0xdd	
 	ntdll.dll!KiUserCallbackDispatcher()  + 0x13	
 	user32.dll!EnumChildWindows()  + 0x17	
 	gkwidget.dll!nsWindow::ProcessMessage(unsigned int msg=0x011ead86, 
unsigned int wParam=0x02b3c4b8, long lParam=0x01419e10, long * 
aRetValue=0x00000000)  Line 4048	C++
 	gkwidget.dll!nsWindow::WindowProc(HWND__ * hWnd=0x00200624, unsigned 
int msg=0x00000000, unsigned int wParam=0x00000000, long lParam=0x03e618f4)  
Line 1346 + 0x10	C++
 	user32.dll!77d43a50() 	
 	user32.dll!77d43b1f() 	
 	user32.dll!GetMessageW()  + 0x125	
 	user32.dll!DispatchMessageW()  + 0xb	
 	appshell.dll!nsAppShellService::Run()  Line 484	C++
 	mozilla.exe!main1(int argc=0x01419e10, char * * argv=0x00000000, 
nsISupports * nativeApp=0x0012aaf0)  Line 1291 + 0x9	C++
 	mozilla.exe!main(int argc=0x00000002, char * * argv=0x002a40a0)  Line 
1678 + 0x16	C++
 	mozilla.exe!WinMain(HINSTANCE__ * __formal=0x00400000, HINSTANCE__ * 
__formal=0x00400000, char * args=0x00152336, HINSTANCE__ * 
__formal=0x00400000)  Line 1702 + 0x17	C++
 	mozilla.exe!WinMainCRTStartup()  Line 392 + 0xf	C
 	kernel32.dll!GetCurrentDirectoryW()  + 0x44	

The line that crashed is:
            end = fp->spbase + fp->script->depth;
00FDB330  mov         edx,dword ptr [edx+20h] 

A previous crash I had yesterday crashed in the following line pair:
            for (vp = fp->sp; vp < end; vp++)
                *vp = JSVAL_VOID;

So i figured it's time for me to report the problem. From reading the other 
bugs, this is probably a problem relating to venkman and reentering xpconnect.

-	cx	0x00dfbcf8 {links={next=0x02a1aeb0 {next=0x0242f7e0 
{next=0x02cecb40 prev=0x02a1aeb0 } prev=0x00dfbcf8 {next=0x02a1aeb0 
prev=0x02b1f310 } } prev=0x02b1f310 {next=0x00dfbcf8 {next=0x02a1aeb0 
prev=0x02b1f310 } prev=0x0264b438 {next=0x02b1f310 prev=0x02a9deb0 } } } 
interpLevel=0x00000003 stackLimit=0x00000000 ...}	JSContext *

most of fp seems to be something approximating garbage
-	fp	0x0012aaf0 {callobj=0x00000045 {map=??? slots=??? } 
argsobj=0x00151378 {map=0x03335d08 {nrefs=0x001520a0 ops=0x005c003f 
{newObjectMap=0x00000000 destroyObjectMap=0x00000000 
lookupProperty=0x00000000 ...} nslots=0x003a0043 ...} slots=0x1a100004 } 
varobj=0x00150000 {map=0x000000c8 {nrefs=??? ops=??? nslots=??? ...} 
slots=0x00000100 } ...}	JSStackFrame *
+	callobj	0x00000045 {map=??? slots=??? }	JSObject *
+	argsobj	0x00151378 {map=0x03335d08 {nrefs=0x001520a0 ops=0x005c003f 
{newObjectMap=0x00000000 destroyObjectMap=0x00000000 
lookupProperty=0x00000000 ...} nslots=0x003a0043 ...} slots=0x1a100004 }
	JSObject *
+	varobj	0x00150000 {map=0x000000c8 {nrefs=??? ops=??? nslots=??? ...} 
slots=0x00000100 }	JSObject *
+	script	0x001520a0 {code=0x001841c0 "ˆE5?" length=0x005c003f 
main=0x003a0043 "" ...}	JSScript *
+	fun	0x0012aaf0 {nrefs=0x00000045 object=0x00151378 {map=0x03335d08 
{nrefs=0x001520a0 ops=0x005c003f {newObjectMap=0x00000000 
destroyObjectMap=0x00000000 lookupProperty=0x00000000 ...} 
nslots=0x003a0043 ...} slots=0x1a100004 } native=0x00150000 ...}
	JSFunction *
+	thisp	0x7c00118f {map=0xfffec6e8 {nrefs=??? ops=??? nslots=??? ...} 
slots=0x448bc3ff }	JSObject *
	argc	0x0012ad38	unsigned int
+	argv	0x77fa88f0	long *
	rval	0x77f53870	long
	nvars	0xffffffff	unsigned int
+	vars	0x77f944a8	long *
+	down	0x77f57d70 {callobj=0x7589f08b {map=??? slots=??? } 
argsobj=0x0ff685e0 {map=??? slots=??? } varobj=0x0000c584 {map=??? 
slots=??? } ...}	JSStackFrame *
	annotation	0x77f58a3a	void *
+	scopeChain	0x00000000 {map=??? slots=??? }	JSObject *
+	pc	0x0017c350 "Xþ"	unsigned char *
+	sp	0x00000000	long *
+	spbase	0x2c870b94	long *
	sharpDepth	0x00000000	unsigned int
+	sharpArray	0x01340654 PL_DHashMatchEntryStub	JSObject *
	flags	0x00000017	unsigned long
+	dormantNext	0x7c03dfb0 {callobj=0xffffffff {map=??? slots=??? } 
argsobj=0x00000000 {map=??? slots=??? } varobj=0x7c00c03a $L19567 ...}
	JSStackFrame *
+	objAtomMap	0x0012ab64 {vector=0x02381180 length=0x00000001 }
	JSAtomMap *

So. fp->sp is null, the previous crash had fp->sp being garbage.

Comment 1

[Bob Clary [:bc] (inactive)]

Attachment: stack from icq.com

I see this as well while debugging a page on icq.com.

Comment 2

[Brendan Eich [:brendan]]

Confirming based on bc's testimony.  Did you say that the mark value was 3? 
That's really weird.  It suggests cx is trash, to say the least!

Is this the "safe context" being used?  It would seem so.

Anyone who can, please purify or valgrind icq.com.  bc, how would one reproduce
the crash on that site?

/be

Comment 3

[Bob Clary [:bc] (inactive)]

I originally saw this crash when debugging
http://web.icq.com/universe/lobby/1,,,00.html
using 1.7/winxp debug build


I had logged in, opened the page, then opened venkman, set stop, reloaded and
was single stepping through the page when I crashed. I have tried several more
times to reproduce the crash and have been unsuccessful. 

Comment 4

[timeless]

talkback-public lists about 315 crashes w/ this signature. there seem to be a
few slightly different traces but they can probably be grouped into 5 or fewer
paths. some comments seem to implicate common tasks. perhaps someone could get a
more reproducable case from some of the reporters?

Comment 5

[timeless]

Attachment: crash w/ 1.7bish

Comment 6

[Tony Mechelynck [:tonymec]]

I "think" I got the same crash, see TB12498125Z (but I'm no specialist, please check it).

- Access violation @ js_AllocStack 3e09427b
- Windows XP 2600.xpsp_sp2_gdr.050301-1519 (Service Pack 2)
- Browser "Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051201 Firefox/1.5", build ID:2005120103
- jsinterp.c line 390
- Don't know how to reproduce the crash (didn't try, was nothing obvious I had done to trigger it).

Comment 7

[Wayne Mery (:wsmwk)]

(In reply to comment #6)
> I "think" I got the same crash, see TB12498125Z (but I'm no specialist, please
> check it).

rest of stack is not similar.

However, amazingly enough, js_AllocStack is a big crasher for FF 1.5 (#28). But no bugs other than this one have AllocStack in summary.

Comment 8

[Tony Mechelynck [:tonymec]]

(In reply to comment #7)
> (In reply to comment #6)
> > I "think" I got the same crash, see TB12498125Z (but I'm no specialist, please
> > check it).
> 
> rest of stack is not similar.
> 
> However, amazingly enough, js_AllocStack is a big crasher for FF 1.5 (#28). But
> no bugs other than this one have AllocStack in summary.
> 

OK, well if it's not the same, then I've provisionally filed TB12498125Z as bug 320256 under Firefox/General/1.5 Branch. Feel free to reclassify ;-)

Comment 9

[Brendan Eich [:brendan]]

jay, anyone: do the talkback reports show a consistent caller and even grand-caller of js_AllocStack?  Here in timeless's comment 0, the caller is nsXPCWrappedJSClass::CallMethod.  Over in bug 320356 the caller is js_InternalInvoke, from JS_CallFunctionValue, from DOM event handler dispatch.

I agree these are distinct bugs.  The signature needs to include more than the top frame of the stack.  In that light, bug 320356 is unlikely to be a JS engine bug. It's probably a DOM or embedding bug where a destroyed JSContext is being used by faulty code that passes the bad pointer into the JS engine.

/be

Comment 10

[Brendan Eich [:brendan]]

(In reply to comment #9)

Argh, how did I mistype bug 320256 twice?!  Sigh.  I meant bug 320256, repeat: bug 320256. ;-)

/be

Comment 12

[John J. Barton]

(In reply to comment #11)
> *** Bug 400618 has been marked as a duplicate of this bug. ***
> 
In my opinion 400618 is a better place to start work. It has a clear way to produce the crash.  John.

Comment 13

[Justin Dolske [:Dolske]]

I can't reproduce this using the steps described in testcase from bug 400618 (attachment 285672 [details]), reloading each 5 times. [FF3 nightly, FB 1.2 tip, OS X]

That testcase was for FB1.2, and some of the "enable these options" no longer exist, maybe the steps-to-reproduce have changed? I don't see js_AllocStack in the topcrashers for 3.0b3, either.

Comment 14

[John J. Barton]

These options from the testcase:
# Firebug->Script->Options
    * ShowEvalSources ON (checked)
    * DecompileScriptsForSource ON (checked)
are wired to "ON" in FB1.2.  On the test case page you should see items on the Script panel label <page-url>/eval/<md5hash> and <page-url>/event/<md5hash>.

Comment 15

[Justin Dolske [:Dolske]]

Yeah, that's what I've got set. I tried some more and still can't reproduce. Are you seeing this on your system? If so, bump this back up to firebug-p1/2? IIRC this was the really annoying Google Ads crasher, so I'm hesitant to knock this down to firebug-p5, but if it seems to work...

Comment 16

[Rob Campbell [:rc] (:robcee)]

Found during triage. are we still seeing these? is this safe to close?

Comment 17

[Wayne Mery (:wsmwk)]

robcee, Simounet no longer sees this.