1309958 - Crash while running nsPluginInstanceOwner::GetNetscapeWindow during InterruptCallback

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect)

Description

[Andrew McCreight [:mccr8]]

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.

Comment 1

[Andrew McCreight [:mccr8]]

I see 83 of these crashes in the last week (this signature, with that release assert).

Comment 2

[Andrew McCreight [:mccr8]]

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.

Comment 3

[Andrew McCreight [:mccr8]]

[Tracking Requested - why for this release]: This is the number 3 top crash on Nightly Windows for 10-13.

Comment 4

[(no longer active)]

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. :(

Comment 5

[Marcia Knous [:marcia]]

Tracking 52+ for the reson in Comment 3.

Comment 6

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Attachment: Use nested(inside_cpow) messages when painting

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.)

Comment 8

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/mozilla-inbound/rev/88b266698d18
Use urgent messages for stuff sent during painting (r=mrbkap)

Comment 9

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/88b266698d18

Comment 10

[Andrew McCreight [:mccr8]]

This is another signature for this crash:
  bp-2efd8c50-d96f-40f3-8ce2-abf292161020

(From the Oct 19 Nightly which I'm pretty sure won't have the fix that landed in comment 9.)