Bug 1639131 Comment 16 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #11)
> I'm not sure. On the face of it the crash looks as though the `sImagesBridgeLock` monitor gets destroyed somewhere between dereferencing the `StaticAutoPtr` [here](https://searchfox.org/mozilla-central/rev/9aa7bebfd169bc2ead00ef596498a406e56bbb85/gfx/layers/ipc/ImageBridgeParent.cpp#119) and when the `MutexAutoLock` actually does the lock. That seems like a pretty narrow window of opportunity. And the only thing that destroys the monitor is the [`ClearOnShutdown`](https://searchfox.org/mozilla-central/rev/9aa7bebfd169bc2ead00ef596498a406e56bbb85/gfx/layers/ipc/ImageBridgeParent.cpp#60) which doesn't run until later. I verified in a local build that for both the GPU process and main process, the `ImageBridgeParent::ShutdownInternal` code runs on the compositor thread while the main thread is blocked [here](https://searchfox.org/mozilla-central/rev/9aa7bebfd169bc2ead00ef596498a406e56bbb85/gfx/layers/ipc/CompositorThread.cpp#132), and that all happens before we even get to the first of the XPCOM shutdown phases [here](https://searchfox.org/mozilla-central/rev/9aa7bebfd169bc2ead00ef596498a406e56bbb85/xpcom/build/XPCOMInit.cpp#608), let alone the [ShutdownFinal](https://searchfox.org/mozilla-central/rev/9aa7bebfd169bc2ead00ef596498a406e56bbb85/xpcom/build/XPCOMInit.cpp#661) phase which clears the monitor.
> 
> So I don't really know what might be causing this. Now that you've duped bugs to this one, and presumably future occurrences will get starred to this bug, we can see how frequent it is. If it's annoyingly frequent I can try and devote more time to digging into it more.

It's a race and a UAF.

We have the sImageBridgesLock being deleted on the main thread and ImageBridgeParent::ShutdownInternal() using it at the same time on the compositor thread.

While a Monitor is thread-safe; a StaticAutoPtr isn't.

> code runs on the compositor thread while the main thread is blocked [here]
The main thread isn't blocked; it runs an event loop until

Back to Bug 1639131 Comment 16