Still looking into this, my current solution is insufficient as it can result in shutdown deadlocks. Further background here is that we have a multiple ownership scenario: [ChromiumCDMParents](https://searchfox.org/mozilla-central/rev/4587d146681b16ff9878a6fdcba53b04f76abe1d/dom/media/gmp/ChromiumCDMParent.h) are owned by both a [ChromiumCDMProxy](https://searchfox.org/mozilla-central/rev/4587d146681b16ff9878a6fdcba53b04f76abe1d/dom/media/gmp/ChromiumCDMProxy.h#117) and a [GMPContentParent](https://searchfox.org/mozilla-central/rev/4587d146681b16ff9878a6fdcba53b04f76abe1d/dom/media/gmp/GMPContentParent.h#89). Comment 9 outlines the issue as to what is happening on the side of the `GMPContentParent`. A simple diagram of ownership here, where -> is used to point to the owner of an object: `ChromiumCDMParent -> GMPContentParent -> GMPServiceChild` If we start destroying from `GMPServiceChild` before the `ChromiumCDMParent` has been destroyed, we get this bug. To avoid this, `ChromiumCDMParent` needs to call `ChromiumCDMDestroyed`, which it does from [`Recv__delete__`](https://searchfox.org/mozilla-central/rev/4587d146681b16ff9878a6fdcba53b04f76abe1d/dom/media/gmp/ChromiumCDMParent.cpp#) or [`ActorDestroy`](https://searchfox.org/mozilla-central/rev/4587d146681b16ff9878a6fdcba53b04f76abe1d/dom/media/gmp/ChromiumCDMParent.cpp#822). However, we also have another set of ownership of `ChromiumCDMParent`: `ChromiumCDMParent -> ChromiumCDMProxy -> MediaKeys` Here, we expect the `ChormiumCDMProxy` to [shutdown](https://searchfox.org/mozilla-central/rev/4587d146681b16ff9878a6fdcba53b04f76abe1d/dom/media/gmp/ChromiumCDMProxy.cpp#311) the `ChromiumCDMParent`. The shutdown should (eventually) result in the removal form the `GMPServiceChild` side. `ChromiumCDMProxy` shutdown looks like it should typically result from `MediaKeys` [shutdown](https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/dom/media/eme/MediaKeys.cpp#89), which happens in the `MeidaKeys` dtor (for the happy path). With some extra logging in `~GMPContentParent` to show if we still have elements in `mChromiumCDMs` at destruction, I'm able to get logs showing if we're going to hit our problematic assert or not. Running one of the problematic tests: `./mach wpt testing/web-platform/tests/encrypted-media/clearkey-generate-request-disallowed-input.https.html` gives me a wpt results window. If I hold this Window open for ~15 seconds after the test has run, then my logs show the MediaKeys being destroyed and shutdown of other components happening as expected. If I close the Window immediately after the test run, the MediaKeys is not destroyed on time and the assertion/this bug is hit. So something is keeping the MediaKeys alive longer than we'd expect, though if we wait awhile, whatever it is dies. Digging further, I suspect it could be related to the pending `MediaKeySessions` [stored](https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/dom/media/eme/MediaKeys.h#169) by `MediaKeys`. If I log in the `MediaKeySession` dtor, the pending sessions are destroyed after waiting ~15 seconds from test finish, and their destruction precedes `MediaKeys` shutting down. Looks like the `MediaKeys` and the pending `MediaKeySessions` form cycle. I'm not particularly familiar with how cycle collection takes place, but wonder if the time it takes for the cycle collector to move though and clobber the cycle is why this works if I wait awhile?
Bug 1522547 Comment 11 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
Still looking into this, my current solution is insufficient as it can result in shutdown deadlocks. Further background here is that we have a multiple ownership scenario: [ChromiumCDMParents](https://searchfox.org/mozilla-central/rev/4587d146681b16ff9878a6fdcba53b04f76abe1d/dom/media/gmp/ChromiumCDMParent.h) are owned by both a [ChromiumCDMProxy](https://searchfox.org/mozilla-central/rev/4587d146681b16ff9878a6fdcba53b04f76abe1d/dom/media/gmp/ChromiumCDMProxy.h#117) and a [GMPContentParent](https://searchfox.org/mozilla-central/rev/4587d146681b16ff9878a6fdcba53b04f76abe1d/dom/media/gmp/GMPContentParent.h#89). Comment 9 outlines the issue as to what is happening on the side of the `GMPContentParent`. A simple diagram of ownership here, where -> is used to point to the owner of an object: `ChromiumCDMParent -> GMPContentParent -> GMPServiceChild` If we start destroying from `GMPServiceChild` before the `ChromiumCDMParent` has been destroyed, we get this bug. To avoid this, `ChromiumCDMParent` needs to call `ChromiumCDMDestroyed`, which it does from [`Recv__delete__`](https://searchfox.org/mozilla-central/rev/4587d146681b16ff9878a6fdcba53b04f76abe1d/dom/media/gmp/ChromiumCDMParent.cpp#) or [`ActorDestroy`](https://searchfox.org/mozilla-central/rev/4587d146681b16ff9878a6fdcba53b04f76abe1d/dom/media/gmp/ChromiumCDMParent.cpp#822). However, we also have another set of ownership of `ChromiumCDMParent`: `ChromiumCDMParent -> ChromiumCDMProxy -> MediaKeys` Here, we expect the `ChormiumCDMProxy` to [shutdown](https://searchfox.org/mozilla-central/rev/4587d146681b16ff9878a6fdcba53b04f76abe1d/dom/media/gmp/ChromiumCDMProxy.cpp#311) the `ChromiumCDMParent`. The shutdown should (eventually) result in the removal form the `GMPServiceChild` side. `ChromiumCDMProxy` shutdown looks like it should typically result from `MediaKeys` [shutdown](https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/dom/media/eme/MediaKeys.cpp#89), which happens in the `MeidaKeys` dtor, (edit) or by the [HTMLMediaElement](https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/dom/html/HTMLMediaElement.cpp#5935) (which would make sense here, but we seem to not be hitting). With some extra logging in `~GMPContentParent` to show if we still have elements in `mChromiumCDMs` at destruction, I'm able to get logs showing if we're going to hit our problematic assert or not. Running one of the problematic tests: `./mach wpt testing/web-platform/tests/encrypted-media/clearkey-generate-request-disallowed-input.https.html` gives me a wpt results window. If I hold this Window open for ~15 seconds after the test has run, then my logs show the MediaKeys being destroyed and shutdown of other components happening as expected. If I close the Window immediately after the test run, the MediaKeys is not destroyed on time and the assertion/this bug is hit. So something is keeping the MediaKeys alive longer than we'd expect, though if we wait awhile, whatever it is dies. Digging further, I suspect it could be related to the pending `MediaKeySessions` [stored](https://searchfox.org/mozilla-central/rev/b36e97fc776635655e84f2048ff59f38fa8a4626/dom/media/eme/MediaKeys.h#169) by `MediaKeys`. If I log in the `MediaKeySession` dtor, the pending sessions are destroyed after waiting ~15 seconds from test finish, and their destruction precedes `MediaKeys` shutting down. Looks like the `MediaKeys` and the pending `MediaKeySessions` form cycle. I'm not particularly familiar with how cycle collection takes place, but wonder if the time it takes for the cycle collector to move though and clobber the cycle is why this works if I wait awhile?