This bug was filed from the Socorro interface and is report bp-1d1f1edd-f93b-4191-a2c3-c82ea0171224. ============================================================= Seen while looking at nightly crash stats - top crash of fennec using 20171223100227. 32 crashes/30 installs in 2 days. Top 10 frames of crashing thread: 0 libxul.so style::stylist::{{impl}}::add_stylesheet<style::gecko::data::GeckoStyleSheet> src/libcore/ptr.rs:328 1 libxul.so geckoservo::glue::Servo_StyleSet_FlushStyleSheets servo/components/style/stylist.rs:110 2 libxul.so mozilla::ServoStyleSet::UpdateStylist layout/style/ServoStyleSet.cpp:1378 3 libxul.so mozilla::ServoStyleSet::BuildFontFeatureValueSet layout/style/ServoStyleSet.cpp:1349 4 libxul.so mozilla::StyleSetHandle::Ptr::BuildFontFeatureValueSet layout/style/StyleSetHandleInlines.h:364 5 libxul.so nsPresContext::FlushFontFeatureValues layout/base/nsPresContext.cpp:3150 6 libxul.so mozilla::PresShell::DoFlushPendingNotifications layout/base/PresShell.cpp:4205 7 libxul.so nsViewManager::CallWillPaintOnObservers view/nsViewManager.cpp:1138 8 libxul.so nsViewManager::ProcessPendingUpdates view/nsViewManager.cpp:1100 9 libxul.so nsRefreshDriver::Tick layout/base/nsRefreshDriver.cpp:2046 =============================================================

Looks like null derefs and there are no URLs or comments... Also the stack points to a function which is somewhat big, so it's not clear what the null object is... I can try to take a more careful look, or adding a couple of extra assertions around the objects that function touches that come from Gecko to see what's up with that.

Setting priority P3 because this crash's volume is very low. Mac crash report bp-58a90d85-259c-475a-994e-0b6610180107 has crash reason "Locked::read_with called with a guard from an unrelated SharedRwLock".

(In reply to Chris Peterson [:cpeterson] from comment #2) > Setting priority P3 because this crash's volume is very low. > > Mac crash report bp-58a90d85-259c-475a-994e-0b6610180107 has crash reason > "Locked::read_with called with a guard from an unrelated SharedRwLock". That is... "impossible", since we only use a single SharedRwLock...