Closed Bug 1309958 Opened 3 years ago Closed 3 years ago

Crash while running nsPluginInstanceOwner::GetNetscapeWindow during InterruptCallback


(Core :: Plug-ins, defect, critical)

Windows 10
Not set



Tracking Status
firefox49 --- unaffected
firefox-esr45 --- unaffected
firefox50 --- unaffected
firefox51 --- unaffected
firefox52 + fixed


(Reporter: mccr8, Assigned: billm)



(4 keywords)

Crash Data


(1 file)

This bug was filed from the Socorro interface and is 
report bp-0dc31218-8fe0-4d77-9759-99f602161013.

I did a search on crash stats for MOZ_CRASH reason of MOZ_RELEASE_ASSERT(rt->allowGCBarriers()), and this is one of the top hits. Lots of URLs on plugin-related sites. It looks like the interrupt callback calls nsIDocument::EnumerateActivityObservers(void (*)(nsISupports*, void*), void*), which ends up in nsPluginInstanceOwner::GetNetscapeWindow(void*), which then tries to send a sync message to the parent, and the reply is somehow via PJavaScriptChild::OnMessageReceived which ends up in nsWrapperCache::GetWrapper() which hits the assert.
I see 83 of these crashes in the last week (this signature, with that release assert).
Flags: needinfo?(wmccloskey)
It looks like [@ SandboxPrivate::GetGlobalJSObject ] is a less common variation on this crash. There are only 7 of these crashes, and they are almost all from a single install time, but they have the same basic pattern of a call into GetNetscapeWindow ending up in PJavaScriptChild::OnMessageReceived.
Crash Signature: [@ nsWrapperCache::GetWrapper] → [@ nsWrapperCache::GetWrapper] [@ SandboxPrivate::GetGlobalJSObject ]
Summary: Crash in nsWrapperCache::GetWrapper during InterruptCallback → Crash while running nsPluginInstanceOwner::GetNetscapeWindow during InterruptCallback
[Tracking Requested - why for this release]: This is the number 3 top crash on Nightly Windows for 10-13.
One possible workaround may be not doing this if the page has a plugin instantiated on it?

Generally it seems like we should have an assertion going off when getting to NotifyObservers() off of an interrupt callback.  Basically arbitrary things can happen from that point on. :(
Component: JavaScript Engine → Plug-ins
Tracking 52+ for the reson in Comment 3.
The problem here is that we're sending a sync message during painting, and from there we can run CPOW requests. I think we should try to mark any sync messages sent during painting as nested(inside_cpow). That way we'll never process CPOWs while waiting for a response. Instead, the parent will process these messages while waiting for its CPOW response.

(Note that nested(inside_cpow) used to be prio(urgent) until we changed the name.)
Assignee: nobody → wmccloskey
Flags: needinfo?(wmccloskey)
Attachment #8801405 - Flags: review?(mrbkap)
Duplicate of this bug: 1310843
Attachment #8801405 - Flags: review?(mrbkap) → review+
Pushed by
Use urgent messages for stuff sent during painting (r=mrbkap)
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla52
This is another signature for this crash:

(From the Oct 19 Nightly which I'm pretty sure won't have the fix that landed in comment 9.)
Crash Signature: [@ nsWrapperCache::GetWrapper] [@ SandboxPrivate::GetGlobalJSObject ] → [@ nsWrapperCache::GetWrapper] [@ SandboxPrivate::GetGlobalJSObject ] [@ nsWrapperCache::GetWrapper const ]
Version: unspecified → Trunk
You need to log in before you can comment on or make changes to this bug.