If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Crash when executing XBL constructor for "plugin crashed" binding

RESOLVED INVALID

Status

()

Core
IPC
--
blocker
RESOLVED INVALID
8 years ago
25 days ago

People

(Reporter: Dolske, Unassigned)

Tracking

({crash})

Trunk
x86
Windows 7
crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

8 years ago
With my Patch v.1 from bug 538910 (which adds the "plugin crashed" UI), if you uncomment the |dump("I'm crashing now.")| the browser will crash as soon as the binding is attached as the <constructor> run.

I'm triggering this with a debug build using the testplugin's .crash() method.

Access violation reading location 0x00000004.

Stack:

xul.dll!nsCOMPtr<nsIPluginInstance>::nsCOMPtr<nsIPluginInstance>   Line 554
xul.dll!PluginDestructionGuard::PluginDestructionGuard   Line 294
xul.dll!NPObjWrapper_NewResolve   Line 1580
mozjs.dll!js_LookupPropertyWithFlags
mozjs.dll!js_LookupProperty
mozjs.dll!JSObject::lookupProperty
mozjs.dll!js_FindPropertyHelper
mozjs.dll!js_Interpret
mozjs.dll!js_Invoke
mozjs.dll!js_InternalInvoke
mozjs.dll!JS_CallFunctionValue
xul.dll!nsXBLProtoImplAnonymousMethod::Execute
xul.dll!nsXBLPrototypeBinding::BindingAttached
xul.dll!nsXBLBinding::ExecuteAttachedHandler
xul.dll!nsBindingManager::ProcessAttachedQueue
xul.dll!PresShell::FlushPendingNotifications
xul.dll!nsRefreshDriver::Notify
xul.dll!nsTimerImpl::Fire
xul.dll!nsTimerEvent::Run
xul.dll!nsThread::ProcessNextEvent
(Reporter)

Comment 1

8 years ago
I'm probably going to not use any JS in the XBL for bug 538910, because if the user has JavaScript disabled in the page it won't run. But I don't know if this can still be tickled some other way.
(Reporter)

Comment 2

8 years ago
[See also bug 539851, the binding isn't being attached (and then crashing) until I mouseover where the plugin was.]

Updated

8 years ago
Flags: wanted-fennec1.0?
(Reporter)

Updated

8 years ago
Flags: wanted-fennec1.0?

Comment 3

8 years ago
It's possible that sometime in between the plugin crashing/ActorDestroy sequence and when we fire the PluginCrash notification to the pluginhost that things are getting confused. It would be nice to know what object is in question... it may be the prototype object attached to the plugin DOM node.
(Reporter)

Comment 4

8 years ago
Hmm, I can also get a similar stack (no XBL on stack, no XBL constructor) by:

1) load page with testplugin
2) invoke <object>.crash()
3) reload
4) invoke <object>.crash()
5) invoke <object>.crash()

Note that there's no reload after step 4. The reload in step 3 is required to trigger the browser crash.
(Reporter)

Updated

8 years ago
No longer blocks: 538910

Updated

25 days ago
Status: NEW → RESOLVED
Last Resolved: 25 days ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.