1405621 - stylo: Crash in hashglobe::hash_map::Entry<T>::or_insert_with<T> smallvec::SmallVec<T>

Status: RESOLVED WORKSFORME

(Core :: Layout, defect, P3)

Description

[baffclan]

This bug was filed from the Socorro interface and is 
report bp-42d6adb7-a301-490e-b1c3-5f0f20171004,
       bp-6c130831-803b-4741-9891-7fcef0171004.
=============================================================

Crashing Thread (0)
Frame 	Module 	Signature 	Source
0 	xul.dll 	hashglobe::hash_map::Entry<style::gecko_string_cache::Atom, smallvec::SmallVec<[style::stylist::Rule; 1]>>::or_insert_with<style::gecko_string_cache::Atom, smallvec::SmallVec<[style::stylist::Rule; 1]>, fn() -> smallvec::SmallVec<[style::stylist::Rule; 1]>> 	servo/components/hashglobe/src/hash_map.rs:1852
1 	xul.dll 	style::stylist::CascadeData::add_stylesheet<style::gecko::data::GeckoStyleSheet> 	servo/components/style/stylist.rs:2028
2 	xul.dll 	geckoservo::glue::Servo_StyleSet_FlushStyleSheets 	servo/ports/geckolib/glue.rs:1053
3 	xul.dll 	mozilla::ServoStyleSet::UpdateStylist() 	layout/style/ServoStyleSet.cpp:1433
4 	xul.dll 	mozilla::ServoStyleSet::BuildFontFeatureValueSet() 	layout/style/ServoStyleSet.cpp:1404
5 	xul.dll 	nsPresContext::FlushFontFeatureValues() 	layout/base/nsPresContext.cpp:3095
6 	xul.dll 	mozilla::PresShell::DoFlushPendingNotifications(mozilla::ChangesToFlush) 	layout/base/PresShell.cpp:4131
7 	xul.dll 	nsIPresShell::FlushPendingNotifications(mozilla::ChangesToFlush) 	layout/base/nsIPresShell.h:566
8 	xul.dll 	mozilla::PresShell::WillPaint() 	layout/base/PresShell.cpp:8482
9 	xul.dll 	nsViewManager::CallWillPaintOnObservers() 	view/nsViewManager.cpp:1138
10 	xul.dll 	nsViewManager::ProcessPendingUpdates() 	view/nsViewManager.cpp:1100
11 	xul.dll 	nsRefreshDriver::Tick(__int64, mozilla::TimeStamp) 	layout/base/nsRefreshDriver.cpp:2082
12 	xul.dll 	mozilla::RefreshDriverTimer::TickDriver(nsRefreshDriver*, __int64, mozilla::TimeStamp) 	layout/base/nsRefreshDriver.cpp:337
13 	xul.dll 	mozilla::RefreshDriverTimer::TickRefreshDrivers(__int64, mozilla::TimeStamp, nsTArray<RefPtr<nsRefreshDriver> >&) 	layout/base/nsRefreshDriver.cpp:307
14 	xul.dll 	mozilla::RefreshDriverTimer::Tick(__int64, mozilla::TimeStamp) 	layout/base/nsRefreshDriver.cpp:329
15 	xul.dll 	mozilla::VsyncRefreshDriverTimer::RunRefreshDrivers(mozilla::TimeStamp) 	layout/base/nsRefreshDriver.cpp:770
16 	xul.dll 	mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::TickRefreshDriver(mozilla::TimeStamp) 	layout/base/nsRefreshDriver.cpp:683
17 	xul.dll 	mozilla::VsyncRefreshDriverTimer::RefreshDriverVsyncObserver::ParentProcessVsyncNotifier::Run() 	layout/base/nsRefreshDriver.cpp:529
18 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp:1039
19 	xul.dll 	mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) 	ipc/glue/MessagePump.cpp:97
20 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc:319
21 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc:299
22 	xul.dll 	nsBaseAppShell::Run() 	widget/nsBaseAppShell.cpp:158
23 	xul.dll 	nsAppShell::Run() 	widget/windows/nsAppShell.cpp:230
24 	xul.dll 	nsAppStartup::Run() 	toolkit/components/startup/nsAppStartup.cpp:288
25 	xul.dll 	XREMain::XRE_mainRun() 	toolkit/xre/nsAppRunner.cpp:4701
26 	xul.dll 	XREMain::XRE_main(int, char** const, mozilla::BootstrapConfig const&) 	toolkit/xre/nsAppRunner.cpp:4865
27 	xul.dll 	XRE_main(int, char** const, mozilla::BootstrapConfig const&) 	toolkit/xre/nsAppRunner.cpp:4960
28 	firefox.exe 	NS_internal_main(int, char**, char**) 	browser/app/nsBrowserApp.cpp:304
29 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp:111
30 	firefox.exe 	__scrt_common_main_seh 	f:/dd/vctools/crt/vcstartup/src/startup/exe_common.inl:253
31 	kernel32.dll 	BaseThreadInitThunk 	
32 	ntdll.dll 	RtlUserThreadStart 	



Application Basics: 
Name: Firefox
Version: 58.0a1
Build ID: 20171003220138
Update Channel: nightly
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0
OS: Windows_NT 10.0

Comment 1

[Jet Villegas (inactive)]

Stack indicates accessing a null object. Xidorn: WDYT?

Comment 2

[Xidorn Quan [:xidorn] UTC+10]

Sounds like the HashMap-related corruption which several people are investigating at the moment. That issue mostly happens during cascading probably because that is run more frequently than updating stylist. But I can imagine the same kind of corruption can affect stylist updating as well.

If there could be a reliable way to reproduce this, it would be helpful to understand whether they are the same reason, and if so, helps diagnosing things there.

Comment 3

[Chris Peterson [:cpeterson]]

status-firefox57=affected because we have crash reports from both 58.0a1 and 57.0b.

Comment 4

[Bobby Holley (:bholley)]

We're tracking this corruption in enough places that this doesn't need to be p2.

Comment 5

[Daniel Veditz [:dveditz]]

This particular -symptom- doesn't appear exploitable, but it's related to a bigger hashmap issue we're dealing with so I'll leave it hidden for now.

Comment 6

[Chris Peterson [:cpeterson]]

status-firefox57=wontfix unless someone thinks this bug should block 57

Comment 7

[Marcia Knous [:marcia]]

Adding a Windows 7 specific crash signature showing up in nightly.

Comment 8

[Randell Jesup [:jesup] (needinfo me)]

The new signature appears to be all null-deref's (so far).  The older signature appears to have mostly null-derefs, but with a few random address crashes.  These seem somewhat random.  They *might* be ram bitflips or other "random" errors hit when looking at hashmaps... 

emilio: who was investigating the other hashmap issue that turned out to be (mostly?) ram corruption/flips?

Comment 9

[Emilio Cobos Álvarez (:emilio)]

I guess I took a look for a while, whithout much success. It's weird that this one happens during insertion, instead of deletion.

Comment 10

[Manish Goregaokar [:manishearth]]

I was investigating it, but as far as we could tell it was just random flips. It persisted after switching over the hashmap implementation.

There was nothing that would prevent the bug from being hit on insertion in the past either; it was just more likely to occur on deletion because deletion goes through the entire map.

Comment 11

[Daniel Holbert [:dholbert]]

Zero crashes over the last 6 months (which I believe is all the data we've got), so it seems this became WORKSFORME.

(Or possibly the crash signature changed for one reason or another, in which case it's tracked elsewhere if volume was high enough to merit a new bug for the new signature.)