crash on Silverlight update page [@NPObjWrapper_NewResolve]

RESOLVED FIXED in mozilla2.0b12

Status

()

defect
RESOLVED FIXED
9 years ago
6 years ago

People

(Reporter: jaas, Assigned: benjamin)

Tracking

({crash, topcrash})

Trunk
mozilla2.0b12
All
macOS
Points:
---

Firefox Tracking Flags

(blocking2.0 final+)

Details

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

Attachments

(1 attachment)

Reporter

Description

9 years ago
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.
Reporter

Updated

9 years ago
blocking2.0: --- → ?
Reporter

Comment 1

9 years ago
From when it landed and what it touched I'm suspicious of bug 611672.
Assignee

Comment 2

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

Comment 3

9 years ago
Maybe related to bug 543350?
Reporter

Updated

9 years ago
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+
Assignee

Comment 8

9 years ago
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.
Reporter

Comment 10

9 years ago
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.
Assignee

Updated

9 years ago
Whiteboard: [hardblocker]
Assignee

Comment 11

9 years ago
I'll take this for now.
Assignee: mrbkap → benjamin
Status: NEW → ASSIGNED
Assignee

Comment 12

9 years ago
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.
Assignee

Comment 13

9 years ago
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.
Assignee

Updated

9 years ago
Whiteboard: [hardblocker] → [hardblocker] has patch, need review
Reporter

Comment 15

9 years ago
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.
Reporter

Updated

9 years ago
Attachment #509228 - Flags: review?(joshmoz) → review+
Assignee

Updated

9 years ago
Whiteboard: [hardblocker] has patch, need review → [hardblocker] will land after tryserver run finishes

Updated

9 years ago
Whiteboard: [hardblocker] will land after tryserver run finishes → [hardblocker] will land after tryserver run finishes [has patch]

Comment 16

9 years ago
is this fixed in the Win32 20110204 Trunk build?
Yes, this landed today:

http://hg.mozilla.org/mozilla-central/rev/41258e566f2e
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Assignee

Updated

9 years ago
Target Milestone: --- → mozilla2.0b12
Crash Signature: [@NPObjWrapper_NewResolve]
You need to log in before you can comment on or make changes to this bug.