246892 - Firefox crash when this page is opened [@ nsXPCWrappedJSClass::GetInterfaceName ] shockwave plugin?

Status: RESOLVED FIXED

(Core :: XPConnect, defect)

Description

[Francois Ingelrest]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040607 Firefox/0.8.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040607 Firefox/0.8.0+

Firefox simply crashes

Reproducible: Always
Steps to Reproduce:
1.Launch Firefox
2.Go to http://www.hotel-paris-france.biz/la-gare-du-nord.php

Actual Results:  
Firefox crashes

Expected Results:  
Firefox should not crash :)

Comment 1

[Bill Mason]

WFM 20040611 PC/Win2000

Comment 2

[Francois Ingelrest]

Tried again this morning with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7) Gecko/20040614 Firefox/0.9 - WinXP

It works as long as the flash plugin is not installed, but after having
installing it, Firefox always crashes when this site is opened. It seems to be a
problem with the flash animation embedded in the page.

Comment 3

[Francois Ingelrest]

I remarked that all the site icons in my favorites are lost after such a crash:
I go on a website that has a customized icon, it appears in my favorites. I
close firefox, reopen it and the icon is still there. If then I go to the site
that makes firefox crash, all the customized icons are lost. I don't know if I
should open a new bug for this, I'm new here :)

Comment 4

[Scott W. Sander]

I report a Firefox crash on my end as well when visiting that website. It didn't
happen immediately... took several seconds before it happened.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040614 Firefox/0.9

Comment 5

[Alexander Edgren]

Crashed for me with Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7)
Gecko/20040619 Firefox/0.9.0+

Tried todays (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7)
Gecko/20040622 Firefox/0.9.0+) and now it works fine. Fixed?

Comment 6

[Francois Ingelrest]

It is still crashing for me

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040623
Firefox/0.9.0+

Comment 7

[shadytrees]

Works for me, although it never does finish "Loading". Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.7) Gecko/20040619 Firefox/0.9.0+

Comment 8

[Anders Pedersen]

Confirmed crash.

Talkback ID: TB194582K

- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040626
Firefox/0.9.1
- Microsoft Windows 2000 Pro 5.00.2195 SP4

Comment 9

[Adam Hauner]

TB194582K:
nsXPCWrappedJSClass::GetInterfaceName 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappedjsclass.cpp,
line 1591]
nsXPCWrappedJS::CallMethod 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappedjs.cpp,
line 450]
SharedStub 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/xpcom/reflect/xptcall/src/md/win32/xptcstubs.cpp,
line 147]
NPSWF32.dll + 0x614f2 (0x04cf14f2)
NPSWF32.dll + 0x5dec5 (0x04cedec5)
NPSWF32.dll + 0x52397 (0x04ce2397)
NPSWF32.dll + 0x4b304 (0x04cdb304)
NPSWF32.dll + 0x4b6ac (0x04cdb6ac)
NPSWF32.dll + 0x4be6f (0x04cdbe6f)
NPSWF32.dll + 0x5f9db (0x04cef9db)
NPSWF32.dll + 0x5d5a2 (0x04ced5a2)
USER32.DLL + 0x1ef0 (0x77e11ef0)
USER32.DLL + 0x204c (0x77e1204c)
USER32.DLL + 0x21af (0x77e121af)
nsAppShellService::Run 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsAppShellService.cpp,
line 495]
main 
[c:/builds/tinderbox/firefox-0.9.1/WINNT_5.0_Clobber/mozilla/browser/app/nsBrowserApp.cpp,
line 58]
KERNEL32.DLL + 0x11af6 (0x7c581af6)
(bug 248071 and bug 241521 has same signature, but different stack)

Anders Pedersen: Could you reproduce with nightbuild on Aviary Branch?

Comment 10

[Anders Pedersen]

Yep, can reproduce it with the latest aviary branch nightly (win32, zip build).

I tried to access the URL once without the Macromedia Flash Player installed and
then the browser didn't crash. But after installing it same thing happened as
last time. 

Confirmed crash. Talkback ID: TB219303Q

- Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040703
Firefox/0.9.0+
- Shockwave Flash 7.0 r19
- Microsoft Windows 2000 Pro 5.00.2195 SP4

Comment 11

[Adam Hauner]

Marking NEW per Anders' repro.
-> XPConnect ?

Comment 12

[Christian 'CeeJay' Jensen]

As per comment #7 this also WFM but never finishes "Loading".

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040722
Firefox/0.9.1+

Comment 13

[David Bradley]

Well something really bad has happened. I suspect what ever object the plugin is
trying to talk to is dead or corrupted. Given that CallMethod should never be
invoking GetInterfaceName since it's not a XPCOM method. I'll have to install
the flash plugin on my build and see what happens.

Comment 14

[Jay Patel [:jay]]

Can't get it to crash with: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.7) Gecko/20040727 Firefox/0.9.1+

The Flash animation just says "Loading" and nothing happens.

Comment 15

[David Bradley]

Attachment: Purify stacks for crash

ns4xPluginInstance::Stop is called, which releases the wrapped JS thingy. Then
the plugin tries to call a method on the wrapped JS thingy.

Stop looks to be getting called because the frame the plugin lives in is being
removed. So not sure if this is a poorly designed web page, a problem somewhere
up the chain causing the frame the get destroyed.

At the very least, the shockwave plugin should be addrefing the wrapped JS
thingy it's holding but apparently isn't or the addref/release is off somewhere
else.

I was able to duplicate the crash using a Mozilla trunk build from today.

Comment 16

[David Bradley]

Ok, scratch part of that. The crash is occuring with a win32 event. The
interesting part is that Win32's TranslateMessageEx is calling SharedStub, which
should never occur. So something truly screwy is going on. I would suspect stack
corruption, but I would have expected Purify to complain before this error.

It could be a bug in the shockwave plugin, but hard to say at this point.

Comment 17

[David Bradley]

I looked at this under the debugger. I think Purify's stack may have gotten a
little off. The debugger shows the stack coming from the shockwave DLL before
the call to SharedStub. So my original message seems to be on track. It looks
like Shockwave DLL, NPSWF32.dll, is calling a dead wrapped JS object. I'll try
and dig into it a bit further, to see if I can tell whether the shockave DLL is
addref'ing or not.

Comment 18

[David Bradley]

A little more digging, turned up the following script being evaluated. The first
parameter to SetWindow is object that the shockwave plugin is releasing. I'm
about ready to mark this invalid, as it looks like the problem lies in the
shockwave plugin. I'll hold off for a bit in case someone comes up with another
explanation.

javascript: function jsScriptObject(obj)
{
    this.wrappedJSObject = obj;
}

jsScriptObject.prototype = 
{
    evaluate : function(expression) { return new jsScriptObject(eval(expression)); }
};

var plugin = document.embeds['bandepassantehotel'];
plugin.SetWindow(new jsScriptObject(window),1484613409);

Comment 19

[chris hofmann]

jst, can you help on this?  its getting late for 1.0 and this would be a good
one to snag...

Comment 20

[Johnny Stenback (:jst)]

Attachment: Prevent nsXPCWrappedJSClass's from going away while its code is on the stack.

This fixes the crash in xpconnect code, but it doesn't fix the while crash on
this site. The problem here is that the site ends up executing JS code through
the flash player and the JS code ends up deleting the flash player from the
tree, so the flash player is destroyed while we're calling through it. Part of
the problem is that the nsXPCWrappedJSClass on which we were making a call was
deleted, and that problem is fixed here, but the rest is much much worse, the
remaining crash is in windows code when the we're unrolling to the flash plugin
after it's been destroyed, and the plugin doesn't deal.

Not sure there's much *we* can do about the rest of this crash, but if we'd
make this change we could maybe get Macromedia to fix the remaining crash in
their code.

Comment 21

[David Bradley]

Comment on attachment 161226 [details] [diff] [review]
Prevent nsXPCWrappedJSClass's from going away while its code is on the stack.

r=dbradley

I'm ok with this patch as an iterim fix, but I think this needs to be
investigated further. We also need to watch the perf stats on the tinderbox
when this goes in.

Comment 22

[Johnny Stenback (:jst)]

FWIW, here's the stack for when the nsXPCWrappedJSClass gets deleted:

xpc3250.dll!nsXPCWrappedJSClass::~nsXPCWrappedJSClass() 	C++
xpc3250.dll!nsXPCWrappedJSClass::`scalar deleting destructor'() 	C++
xpc3250.dll!nsXPCWrappedJSClass::Release() 	C++
xpc3250.dll!nsXPCWrappedJS::~nsXPCWrappedJS() 	C++
xpc3250.dll!nsXPCWrappedJS::`scalar deleting destructor'() 	C++
xpc3250.dll!nsXPCWrappedJS::Release() 	C++
npswf32.dll!043eb49a() 	
gklayout.dll!nsObjectFrame::Destroy(aPresContext=0x03249e38) 	C++
gklayout.dll!nsFrameList::DestroyFrames(aPresContext=0x03249e38) 	C++
gklayout.dll!nsContainerFrame::Destroy(aPresContext=0x03249e38) 	C++
gklayout.dll!nsBlockFrame::DoRemoveFrame(aPresContext=0x03249e38,
aDeletedFrame=0x02fed5b4) 	C++
gklayout.dll!nsBlockFrame::RemoveFrame(aPresContext=0x03249e38,
aPresShell={...}, aListName=0x00000000, aOldFrame=0x02fed5b4) 	C++
gklayout.dll!nsFrameManager::RemoveFrame(aParentFrame=0x0328c5a4,
aListName=0x00000000, aOldFrame=0x02fed5b4) 	C++
gklayout.dll!nsCSSFrameConstructor::ContentRemoved(aPresContext=0x03249e38,
aContainer=0x0315ad60, aChild=0x03215200, aIndexInContainer=0x00000001,
aInContentReplaced=0x00000000) 	C++
gklayout.dll!PresShell::ContentRemoved(aDocument=0x02ff7890,
aContainer=0x0315ad60, aChild=0x03215200, aIndexInContainer=0x00000001) 	C++
gklayout.dll!nsDocument::ContentRemoved(aContainer=0x0315ad60,
aChild=0x03215200, aIndexInContainer=0x00000001) 	C++
gklayout.dll!nsHTMLDocument::ContentRemoved(aContainer=0x0315ad60,
aContent=0x03215200, aIndexInContainer=0x00000001) 	C++
gklayout.dll!nsGenericElement::RemoveChildAt(aIndex=0x00000001,
aNotify=0x00000001) 	C++
gklayout.dll!nsGenericElement::doRemoveChild(aElement=0x0315ad60,
aOldChild=0x03215240, aReturn=0x0012d6ec) 	C++
gklayout.dll!nsGenericElement::RemoveChild(aOldChild=0x03215240,
aReturn=0x0012d6ec) 	C++
gklayout.dll!nsHTMLDivElement::RemoveChild(aOldChild=0x03215240,
aReturn=0x0012d6ec) 	C++
gklayout.dll!nsRange::DeleteContents() 	C++
gklayout.dll!nsGenericHTMLElement::SetInnerHTML(aInnerHTML={...}) 	C++
gklayout.dll!nsGenericHTMLElementTearoff::SetInnerHTML(aInnerHTML={...}) 	C++
xpcom.dll!XPTC_InvokeByIndex(that=0x031dfbf0, methodIndex=0x00000009,
paramCount=0x00000001, params=0x0012d900) 	C++
xpc3250.dll!XPCWrappedNative::CallMethod(ccx={...}, mode=CALL_SETTER) 	C++
xpc3250.dll!XPCWrappedNative::SetAttribute(ccx={...}) 	C++
xpc3250.dll!XPC_WN_GetterSetter(cx=0x00b95ee0, obj=0x0274eab8, argc=0x00000001,
argv=0x031f010c, vp=0x0012dbe8) 	C++
js3250.dll!js_Invoke(cx=0x00b95ee0, argc=0x00000001, flags=0x00000002) 	C
js3250.dll!js_InternalInvoke(cx=0x00b95ee0, obj=0x0274eab8, fval=0x0274eaf8,
flags=0x00000000, argc=0x00000001, argv=0x0012e5b8, rval=0x0012e5b8) 	C
js3250.dll!js_InternalGetOrSet(cx=0x00b95ee0, obj=0x0274eab8, id=0x0297ea00,
fval=0x0274eaf8, mode=JSACC_WRITE, argc=0x00000001, argv=0x0012e5b8,
rval=0x0012e5b8) 	C
js3250.dll!js_SetProperty(cx=0x00b95ee0, obj=0x0274eab8, id=0x0297ea00,
vp=0x0012e5b8) 	C
js3250.dll!js_Interpret(cx=0x00b95ee0, result=0x0012e628) 	C
js3250.dll!js_Execute(cx=0x00b95ee0, chain=0x0274e9e0, script=0x031f3cf0,
down=0x0012f058, special=0x00000020, result=0x0012e784) 	C
js3250.dll!obj_eval(cx=0x00b95ee0, obj=0x0277e8f8, argc=0x00000001,
argv=0x031f0058, rval=0x0012e784) 	C
js3250.dll!js_Invoke(cx=0x00b95ee0, argc=0x00000001, flags=0x00000000) 	C
js3250.dll!js_Interpret(cx=0x00b95ee0, result=0x0012f0fc) 	C
js3250.dll!js_Invoke(cx=0x00b95ee0, argc=0x00000001, flags=0x00000002) 	C
xpc3250.dll!nsXPCWrappedJSClass::CallMethod(wrapper=0x031f3c80,
methodIndex=0x0003, info=0x030b9810, nativeParams=0x0012f424) 	C++
xpc3250.dll!nsXPCWrappedJS::CallMethod(methodIndex=0x0003, info=0x030b9810,
params=0x0012f424) 	C++
xpcom.dll!PrepareAndDispatch(self=0x031f3c80, methodIndex=0x00000003,
args=0x0012f4ec, stackBytesToPop=0x0012f4dc) 	C++
xpcom.dll!SharedStub() 	C++
npswf32.dll!043eed2a() 	
npswf32.dll!043ebb65() 	
npswf32.dll!043e1bd7() 	
npswf32.dll!043dc7ff() 	
npswf32.dll!043dce53() 	
npswf32.dll!043ed364() 	
npswf32.dll!043eb22f() 	
user32.dll!77d48709() 	
user32.dll!77d487eb() 	
user32.dll!77d489a5() 	
user32.dll!77d489e8() 	
gkwidget.dll!nsAppShell::Run() 	C++

Comment 23

[Brendan Eich [:brendan]]

Comment on attachment 161226 [details] [diff] [review]
Prevent nsXPCWrappedJSClass's from going away while its code is on the stack.

So is the plugin really doing itself in, or is it using some gecko-frame-based
protocol that nukes everything unconditionally?  If the latter, we ought to
defend.  I'm wondering if this is yet another problem to-do with plugins being
owned by frames (or have we changed to put them in the content tree?).

Sorry if that was all wet! sr=me on this patch.

/be

Comment 24

[Brendan Eich [:brendan]]

Comment on attachment 161226 [details] [diff] [review]
Prevent nsXPCWrappedJSClass's from going away while its code is on the stack.

I'll approve too, this is not going to break anyone, and it should help.

/be

Comment 25

[Johnny Stenback (:jst)]

Fix checked in. Leaving bug open to track the remaining plugin crash.

Comment 26

[timeless]

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

Comment 27

[Wayne Mery (:wsmwk)]

URL http://www.hotel-paris-france.biz/la-gare-du-nord.php is no longer accessible

no crash for https://www.hotel-paris-france.biz/
keep the bug open?

Comment 28

[Wayne Mery (:wsmwk)]

closing fixed - what was left might have been fixed by the plugin or bug 248071?

no testcase 

all nsxpcwrappedjsclass::getinterfacename crashers on talkback are 1.7 (~2004=ancient), none 1.8 branch or 1.9.  I didn't crash using the only two distinctive URLs from the bunch : www.fatimacrusader.com, godall.org