Nightly 58 x64 20171110100139 de_DE @ Debian Testing (KDE, Radeon RX480) main profile: gpu-process, layers force accel, webrender, blob-images, omtp, stylo-chrome I didn't notice it. bp-5569605d-a7d0-4e62-a353-91fe40171111 11.11.17 16:30 begins with: > 0 libxul.so std::_Hashtable<mozilla::wr::FontKey, std::pair<const mozilla::wr::FontKey, mozilla::wr::FontTemplate>, std::allocator<std::pair<const mozilla::wr::FontKey, mozilla::wr::FontTemplate> >, std::__detail::_Select1st, std::equal_to<mozilla::wr::FontKey>, std::hash<mozilla::wr::FontKey>, std::__detail::_Mod_range_hashing, std::__detail::_Default_ranged_hash, std::__detail::_Prime_rehash_policy, std::__detail::_Hashtable_traits<true, false, true> >::_M_find_before_node gcc/include/c++/6.4.0/bits/hashtable.h:1417 There are two other crash reports (build 20171107122447) that are not from me. bp-562465e2-fd54-4b5a-afaf-9da880171108 bp-59223223-cc88-4366-9207-ae5f40171108

Lee, Any idea about this? The wr font handle related problem?

The STL only guarantees that it is safe to simultaneously *read* a container from multiple threads. Here we are however both reading and writing to the structure at the same time in a couple possible ways: 1) sFontDataTable.find() and sFontDataTable[]= are being called via AddFontData from multiple render backend threads if there are multiple windows 2) the blob image worker thread is using GetUnscaledFont() which calls sFontDataTable.find(), and this can be going on while AddFontData from another blob image request that just got kicked off is going on, so that the two requests essentially overlap The simplest thing to do here is just wrap all this junk in a StaticMutex to ensure we're not reading and writing from sFontDataTable at the same time on many threads.

Pushed by lsalzman@mozilla.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/64bbd3645b62 lock access to the blob image font data table. r=nical