Closed Bug 1154513 Opened 9 years ago Closed 9 years ago

[EME] GMP crash crashes browser in Nightly

Categories

(Core :: Audio/Video, defect, P2)

x86_64
All
defect

Tracking

()

RESOLVED FIXED
mozilla40
Tracking Status
firefox38 --- unaffected
firefox39 --- unaffected
firefox40 --- fixed

People

(Reporter: cpearce, Assigned: mozbugz)

References

(Blocks 1 open bug)

Details

Attachments

(1 file, 1 obsolete file)

STR:

* Load http://drmtest2.adobe.com/HTML5AAXSPlayer/2/mse-access/ in Nightly
* Press "Play"
* Create bool pref "media.gmp.plugin.crash" and set to true (or toggle to true)
* Browser crashes!

In my case, the pref already exists and was set to true, so I had to toggle it to false and true.
Assignee: nobody → gsquelart
Nightly only, so P2.
Priority: -- → P2
When shutting down, only try and send a message if the actor hasn't been destroyed (which would destroy the PGMPContentParent, destroying the MessageChannel with it).

Note: This 'if (mIsOpen)' test was removed by Edwin in bug 1072024, in a patch named "1072024-plug-leak.patch", so it is very possible that this new patch here reintroduces a leak -- To be tested thoroughly!
(Just not sure how this would leak, as the other side of the channel is probably very dead, so not sending a message shouldn't matter?!)

Alternatives would be for PGMPContentParent to notify channel users that the channel is dead; or to keep PGMPContentParent (and hence the channel) alive at least as long as all the channel users.
Attachment #8593911 - Flags: review?(cpearce)
I could reproduce the original issue on both Windows and Mac when using a clearkey test page and crashing the plugin. The proposed patch fixes that as well.
OS: Windows 8.1 → All
Comment on attachment 8593911 [details] [diff] [review]
1154513-no-messaging-if-not-open.patch

Cancelling r? for now.
Attachment #8593911 - Flags: review?(cpearce)
I can repro the failure. We're spinning the event loop waiting for async shutdown to complete, in GeckoMediaPluginServiceParent::Observe() in the "profile-change-teardown" case, inside the loop:

    // Wait for plugins to do async shutdown...
    while (mWaitingForPluginsAsyncShutdown) {
      NS_ProcessNextEvent(NS_GetCurrentThread(), true);
    }

mWaitingForPluginsAsyncShutdown is never being unset.

We're also supposed to timeout the async shutdown after 3 seconds, and that's not happening...
After further investigation, I think this patch is probably an acceptable solution.

Debugging shows the following sequence of calls:
0- GMPContentParent::GetGMPDecryptor() -- GMPDecryptorParent is created, mChannel given as raw pointer
 ** kill plugin here **
1- GMPDecryptorParent::ActorDestroy() -- synchronously calls GMPContentParent::DecryptorDestroyed
2- GMPContentParent::DecryptorDestroyed -- here GMPContentParent forgets about GMPDecryptorParent
3- GMPContentParent::ActorDestroy() -- no children left -> kill self
4- GMPContentParent::~GMPContentParent() -- destroys mChannel as well!
5- GMPDecryptorParent::Shutdown() -- calls SendDecryptingComplete(), which crashes because mChannel has been destroyed

We could try and rewire the whole GMP machinery so that GMPDecryptorParent::Shutdown is called *before* GMPContentParent (or just mChannel) is destroyed, but it seems much harder, and in any case it would not really help as messages could not get sent anyway.

The other option of notifying GMPDecryptorParent (that mChannel is dead) is not possible because GMPContentParent forgets about GMPDecryptorParent in step 2 above, some time before the channel destruction.


Try in progress: https://treeherder.mozilla.org/#/jobs?repo=try&revision=04a44047b3a7
Attachment #8593911 - Attachment is obsolete: true
Attachment #8595092 - Flags: review?(cpearce)
Attachment #8595092 - Flags: review?(cpearce) → review+
https://hg.mozilla.org/mozilla-central/rev/5707042f113b
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: