It seems like the VideoParent thread shuts down without waiting for its corresponding protocol to close. It could either wait for ActorDestroy or it could do Close() itself (although it looks like the child is normally responsible for closing). Without doing this, we can end up with messages in the queue that we try to dispatch to a thread that no longer exists, which can trigger UAFs.

This uses the same trick as CompositorBridgeParent to ensure that we've not left any dangling MessageChannels. Bill, I'm having trouble reproducing this, are you able to test that it works? (Or, tell me what to run?)

I think I filed this based on a crash report, but I can't remember now :-(.

Pushed by danderson@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/90cc6db6ad4a Wait for VideoDecoderManagerParents to shut down before destroying the VideoParent thread. (bug 1360697, r=billm)

This doesn't appear thread safe to me. sVideoDecoderManagerThread Is cleared on the main thread while the test of its value is on another.

Which test? The one in VideoDecoderManagerParent::ShutdownThreads happens on the main thread.

My bad. Getting too used to having the taskqueue on which a member runs described via assertion I guess. So the current threading model here wasn't clear to me.