Closed Bug 616400 Opened 13 years ago Closed 12 years ago

crash on Silverlight update page [@NPObjWrapper_NewResolve]


(Core Graveyard :: Plug-ins, defect)

Not set


(blocking2.0 final+)

Tracking Status
blocking2.0 --- final+


(Reporter: jaas, Assigned: benjamin)


(Keywords: crash, topcrash, Whiteboard: [hardblocker] will land after tryserver run finishes [has patch])

Crash Data


(1 file)

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:

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:

All four reports of this in our database for 4.0b8pre have come within the past
two days. Two are from me.
blocking2.0: --- → ?
From when it landed and what it touched I'm suspicious of bug 611672.
I can't reproduce on Windows or IPP mac. I think it's pretty unlikely that bug 611672 is involved.
Maybe related to bug 543350?
blocking2.0: ? → -
Happens to me quite frequently when going to the Mozilla Plugin Check page - when it checks for the new version I get this crash.
It is #5 top crasher on Mac OS X in 4.0b8 for the last week.
Keywords: crash, topcrash
I can reproduce this reliably with the instructions in comment #0. It's on today's nightly: bp-62a5e292-63e4-431e-b840-ba61d2110127
blocking2.0: - → ?
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.
Assignee: nobody → mrbkap
blocking2.0: ? → final+
I think bent might be a better owner for this bug...
That's almost certainly true. I can't even figure out how to get my debug build to admit that I've installed Silverlight.
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.
Whiteboard: [hardblocker]
I'll take this for now.
Assignee: mrbkap → benjamin
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 "", 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 "", 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 "", 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.
Interesting: NPP_New is failing with NPERR_MODULE_LOAD_FAILED_ERROR. This calls NPP_Destroy here:

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

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.
Whiteboard: [hardblocker] → [hardblocker] has patch, need review
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.
Attachment #509228 - Flags: review?(joshmoz) → review+
Whiteboard: [hardblocker] has patch, need review → [hardblocker] will land after tryserver run finishes
Whiteboard: [hardblocker] will land after tryserver run finishes → [hardblocker] will land after tryserver run finishes [has patch]
is this fixed in the Win32 20110204 Trunk build?
Yes, this landed today:
Closed: 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b12
Crash Signature: [@NPObjWrapper_NewResolve]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.