Bugzilla

Okay, I don't see how bug 1833876 could be relevant.

Looking through the code. We're crashing trying to read the raw pointer address owned by the UniquePtr `mShmem` [here](https://searchfox.org/mozilla-central/rev/61aca7cda4b217245d9af5aac5bf49bf0d5ecfe3/gfx/thebes/SharedFontList-impl.h#312). Not dereferencing that address, but reading the value from the UniquePtr. Which I believe indicates it's the `ShmBlock` itself that has been poisoned.

The proto signatures mostly show either `FontList::GetHeader()` or `Pointer::ToPtr()` immediately above in the stack. Each of these call `ShmBlock::Memory()` by accessing the ShmBlock through the `FontList::mBlocks` nsTArray. If this nsTArray was reallocated from underneath the DOM worker thread I believe we could therefore crash in this manner.

In the content process we append to the array in `FontList::ShmBlockAdded()` (called from `gfxPlatformFontList::ShmBlockAdded()`). And clear the list in `FontList::DetachShmBlocks()`. The latter only gets called in the FontList constructor and destructor, so I don't believe could be an issue. But the former seems like it might be.

Jonathan, am I missing anything guarding `FontListmBlocks` anywhere? Should we perhaps be locking `mLock` [here](https://searchfox.org/mozilla-central/rev/61aca7cda4b217245d9af5aac5bf49bf0d5ecfe3/gfx/thebes/gfxPlatformFontList.cpp#2986) ?

Okay, I don't see how bug 1833876 could be relevant.

Looking through the code. We're crashing trying to read the raw pointer address owned by the UniquePtr `mShmem` [here](https://searchfox.org/mozilla-central/rev/61aca7cda4b217245d9af5aac5bf49bf0d5ecfe3/gfx/thebes/SharedFontList-impl.h#312). Not dereferencing that address, but reading the value from the UniquePtr. Which I believe indicates it's the `ShmBlock` itself that has been poisoned.

The proto signatures mostly show either `FontList::GetHeader()` or `Pointer::ToPtr()` immediately above in the stack. Each of these call `ShmBlock::Memory()` by accessing the ShmBlock through the `FontList::mBlocks` nsTArray. If this nsTArray was reallocated from underneath the DOM worker thread I believe we could therefore crash in this manner.

In the content process we append to the array in `FontList::ShmBlockAdded()` (called from `gfxPlatformFontList::ShmBlockAdded()`). And clear the list in `FontList::DetachShmBlocks()`. The latter only gets called in the FontList constructor and destructor, so I don't believe could be an issue. But the former seems like it might be.

Jonathan, am I missing anything guarding `FontList::mBlocks` anywhere? Should we perhaps be locking `mLock` [here](https://searchfox.org/mozilla-central/rev/61aca7cda4b217245d9af5aac5bf49bf0d5ecfe3/gfx/thebes/gfxPlatformFontList.cpp#2986) ?