616400 - crash on Silverlight update page [@NPObjWrapper_NewResolve]

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Josh Aas]

I just crashed trying to update Silverlight via Mozilla's plugincheck page with
the latest Minefield nightly on Mac OS X 10.6.5. I clicked on the update button
for Silverlight and crashed on the following Silverlight page:

http://www.microsoft.com/silverlight/get-started/install/default.aspx

Pretty easy to repro by reloading that URL, I only have to reload the page a
couple of times to get it to happen.

My crash report is here:

http://crash-stats.mozilla.com/report/index/bp-c471f3a3-03df-4c14-b5c7-a76fd2101202

All four reports of this in our database for 4.0b8pre have come within the past
two days. Two are from me.

Comment 1

[Josh Aas]

From when it landed and what it touched I'm suspicious of bug 611672.

Comment 2

[Benjamin Smedberg]

I can't reproduce on Windows or IPP mac. I think it's pretty unlikely that bug 611672 is involved.

Comment 3

[Josh Aas]

Maybe related to bug 543350?

Comment 4

[Marcia Knous [:marcia]]

Happens to me quite frequently when going to the Mozilla Plugin Check page - when it checks for the new version I get this crash.

Comment 5

[Scoobidiver (away)]

It is #5 top crasher on Mac OS X in 4.0b8 for the last week.

Comment 6

[juan becerra [:juanb]]

I can reproduce this reliably with the instructions in comment #0. It's on today's nightly: bp-62a5e292-63e4-431e-b840-ba61d2110127

Comment 7

[Johnny Stenback (:jst)]

I think this needs to block, at least on better understanding what the problem is here, whether it's our code or a plugin bug.

Comment 8

[Benjamin Smedberg]

I think bent might be a better owner for this bug...

Comment 9

[Blake Kaplan (:mrbkap) (inactive)]

That's almost certainly true. I can't even figure out how to get my debug build to admit that I've installed Silverlight.

Comment 10

[Josh Aas]

Blake - my guess is that you're creating an x86_64-only (not universal) build on Mac OS X 10.6. The Silverlight plugin is i386-only, so it requires an i386 plugin container binary in order to load. You can get it working by either 1) cross-compiling an i386 build or 2) creating a universal binary build. The former is easier if you don't need a universal binary build to reproduce the problem.

If this isn't the case just let me know what your environment is and I can take another stab at the problem.

Comment 11

[Benjamin Smedberg]

I'll take this for now.

Comment 12

[Benjamin Smedberg]

I can reproduce this 100% in a debug build. The stack is:

#0  0x012684f4 in nsCOMPtr<nsIPluginInstance>::nsCOMPtr (this=0xbfffc854, aRawPtr=0x63746977) at nsCOMPtr.h:577
#1  0x012687f8 in PluginDestructionGuard::PluginDestructionGuard (this=0xbfffc84c, npp=0x1b4a491c) at nsPluginHost.h:321
#2  0x0128b74e in NPObjWrapper_NewResolve (cx=0x1ef9dad0, obj=0x20cd5e60, id={asBits = 377489568}, flags=5, objp=0xbfffc8d0) at ../../../../../src/modules/plugin/base/src/nsJSNPRuntime.cpp:1644
#3  0x01a8d252 in CallResolveOp (cx=0x1ef9dad0, start=0x20cf2a10, obj=0x20cd5e60, id={asBits = 377489568}, flags=5, objp=0xbfffc9d8, propp=0xbfffc9d0, recursedp=0xbfffc95f) at ../../../src/js/src/jsobj.cpp:4851
#4  0x01a8d52f in js_LookupPropertyWithFlagsInline (cx=0x1ef9dad0, obj=0x20cd5e60, id={asBits = 377489568}, flags=65535, objp=0xbfffc9d8, propp=0xbfffc9d0) at ../../../src/js/src/jsobj.cpp:4924
#5  0x01a9021a in js_GetPropertyHelperWithShapeInline (cx=0x1ef9dad0, obj=0x20cf2a10, receiver=0x20cf2a10, id={asBits = 377489568}, getHow=1, vp=0xbfffcab8, shapeOut=0xbfffca3c, holderOut=0xbfffca38) at ../../../src/js/src/jsobj.cpp:5301
#6  0x01a9067f in js_GetPropertyHelperInline (cx=0x1ef9dad0, obj=0x20cf2a10, receiver=0x20cf2a10, id={asBits = 377489568}, getHow=1, vp=0xbfffcab8) at ../../../src/js/src/jsobj.cpp:5404
#7  0x01a90768 in js_GetPropertyHelper (cx=0x1ef9dad0, obj=0x20cf2a10, id={asBits = 377489568}, getHow=1, vp=0xbfffcab8) at ../../../src/js/src/jsobj.cpp:5410
#8  0x01bf131b in InlineGetProp (f=@0xbfffcb40) at ../../../src/js/src/methodjit/StubCalls.cpp:1904
#9  0x01bf14eb in js::mjit::stubs::GetProp (f=@0xbfffcb40) at ../../../src/js/src/methodjit/StubCalls.cpp:1922
#10 0x01c406c5 in DisabledGetPropIC (f=@0xbfffcb40, pic=0x1c968c90) at ../../../src/js/src/methodjit/PolyIC.cpp:1624
#11 0x1c607a95 in ?? ()
#12 0x01be76de in js::mjit::EnterMethodJIT (cx=0x1ef9dad0, fp=0x16400030, code=0x1c5f78dc, stackLimit=0x1648ca60) at ../../../src/js/src/methodjit/MethodJIT.cpp:748
#13 0x01be77fd in CheckStackAndEnterMethodJIT (cx=0x1ef9dad0, fp=0x16400030, code=0x1c5f78dc) at ../../../src/js/src/methodjit/MethodJIT.cpp:774
#14 0x01be791f in js::mjit::JaegerShot (cx=0x1ef9dad0) at ../../../src/js/src/methodjit/MethodJIT.cpp:791
#15 0x01a6ed9b in js::RunScript (cx=0x1ef9dad0, script=0x1b4bb420, fp=0x16400030) at jsinterp.cpp:658
#16 0x01a6f480 in js::Execute (cx=0x1ef9dad0, chain=0x20c8c0a0, script=0x1b4bb420, prev=0x0, flags=0, result=0x0) at jsinterp.cpp:1027
#17 0x0199f041 in EvaluateUCScriptForPrincipalsCommon (cx=0x1ef9dad0, obj=0x20c8c0a0, principals=0x1f4f6f54, chars=0x1c097550, length=17, filename=0x216093a8 "http://www.microsoft.com/getsilverlight/scripts/Install.js", lineno=57, rval=0x0, compileVersion=JSVERSION_DEFAULT) at ../../../src/js/src/jsapi.cpp:4939
#18 0x0199f383 in JS_EvaluateUCScriptForPrincipalsVersion (cx=0x1ef9dad0, obj=0x20c8c0a0, principals=0x1f4f6f54, chars=0x1c097550, length=17, filename=0x216093a8 "http://www.microsoft.com/getsilverlight/scripts/Install.js", lineno=57, rval=0x0, version=JSVERSION_DEFAULT) at ../../../src/js/src/jsapi.cpp:4955
#19 0x009cfd95 in nsJSContext::EvaluateString (this=0x1ef9d4a0, aScript=@0xbfffcfd4, aScopeObject=0x20c8c0a0, aPrincipal=0x1f4f6f50, aURL=0x216093a8 "http://www.microsoft.com/getsilverlight/scripts/Install.js", aLineNo=57, aVersion=0, aRetValue=0x0, aIsUndefined=0xbfffd03c) at ../../../src/dom/base/nsJSEnvironment.cpp:1554
#20 0x00a081c0 in nsGlobalWindow::RunTimeout (this=0x1c03a260, aTimeout=0x216093f0) at ../../../src/dom/base/nsGlobalWindow.cpp:9090

It appears that in frame #2, the NPObject is

(gdb) p *$16
$17 = {
  <NPObject> = {
    _class = 0x22b6320, 
    referenceCount = 1
  }, 
  members of mozilla::plugins::ParentNPObject: 
  parent = 0x0, 
  invalidated = false
}

Which means that the actor has been destroyed (acceptable, but a bit strange that we're calling a method on a dead actor). LookupNPP, however, is giving a result which appears to be completely bogus:

(gdb) p LookupNPP(npobj)
$18 = (NPP) 0x1b4a491c
(gdb) p *$18
$19 = {
  pdata = 0x732f2f3a, 
  ndata = 0x63746977
}
(gdb) p ('mozilla::plugins::PluginInstanceParent'*) $18->pdata
$20 = ('mozilla::plugins::PluginInstanceParent' *) 0x732f2f3a
(gdb) p * ('mozilla::plugins::PluginInstanceParent'*) $18->pdata
Cannot access memory at address 0x732f2f3a

Going to have to printf-debug some of this, I'm afraid.

Comment 13

[Benjamin Smedberg]

Interesting: NPP_New is failing with NPERR_MODULE_LOAD_FAILED_ERROR. This calls NPP_Destroy here: http://mxr.mozilla.org/mozilla-central/source/dom/plugins/PluginModuleParent.cpp#830

But we never end up calling nsJSNPRuntime::OnPluginDestroy through this codepath:

http://mxr.mozilla.org/mozilla-central/source/modules/plugin/base/src/nsNPAPIPluginInstance.cpp#220

Josh, the current silverlight release is not expected to work in Firefox 4, right? We're still waiting for a new release from Microsoft? If so, I understand and can fix this crash.

Comment 14

[Benjamin Smedberg]

Attachment: Call nsJSNPRuntime::OnPluginDestroy from the failed-init case, rev. 1

Comment 15

[Josh Aas]

In "PluginModuleChild::AnswerPPluginInstanceConstructor" we return "NPERR_MODULE_LOAD_FAILED_ERROR" artificially if NPP_New succeeds but the plugin negotiated Carbon. As far as the plugin is concerned though, creating the instance succeeded, it return NPERR_NO_ERROR. Just wanted to make that clear.

Comment 16

[mattburles]

is this fixed in the Win32 20110204 Trunk build?

Comment 17

[Johnny Stenback (:jst)]

Yes, this landed today:

http://hg.mozilla.org/mozilla-central/rev/41258e566f2e