Closed
Bug 1405621
Opened 7 years ago
Closed 2 years ago
stylo: Crash in hashglobe::hash_map::Entry<T>::or_insert_with<T> smallvec::SmallVec<T>
Categories
(Core :: Layout, defect, P3)
Tracking
()
RESOLVED
WORKSFORME
Tracking | Status | |
---|---|---|
firefox-esr52 | --- | unaffected |
firefox56 | --- | unaffected |
firefox57 | --- | wontfix |
firefox58 | --- | wontfix |
firefox61 | --- | wontfix |
People
(Reporter: baffclan, Unassigned)
References
(Depends on 1 open bug, Blocks 1 open bug)
Details
(Keywords: crash, sec-other, testcase-wanted)
Crash Data
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•7 years ago
|
||
Stack indicates accessing a null object. Xidorn: WDYT?
Comment 2•7 years ago
|
||
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.
Blocks: stylo-crash-reports
Flags: needinfo?(xidorn+moz)
Summary: Crash in hashglobe::hash_map::Entry<T>::or_insert_with<T> smallvec::SmallVec<T> → stylo: Crash in hashglobe::hash_map::Entry<T>::or_insert_with<T> smallvec::SmallVec<T>
Comment 3•7 years ago
|
||
status-firefox57=affected because we have crash reports from both 58.0a1 and 57.0b.
Updated•7 years ago
|
Group: core-security
Updated•7 years ago
|
Group: core-security → layout-core-security
Comment 4•7 years ago
|
||
We're tracking this corruption in enough places that this doesn't need to be p2.
Priority: P2 → P3
Updated•7 years ago
|
Depends on: stylo-hashmap-crashes
Comment 5•7 years ago
|
||
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.
Keywords: sec-other,
testcase-wanted
Comment 6•7 years ago
|
||
status-firefox57=wontfix unless someone thinks this bug should block 57
Comment 7•6 years ago
|
||
Adding a Windows 7 specific crash signature showing up in nightly.
Crash Signature: [@ hashglobe::hash_map::Entry<T>::or_insert_with<T> smallvec::SmallVec<T>] → [@ hashglobe::hash_map::Entry<T>::or_insert_with<T> smallvec::SmallVec<T>]
[@ static struct smallvec::SmallVec<T>* hashglobe::hash_map::Entry<T>::or_insert_with<T> smallvec::SmallVec<T>]
status-firefox61:
--- → affected
Comment 8•6 years ago
|
||
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?
Flags: needinfo?(emilio)
Comment 9•6 years ago
|
||
I guess I took a look for a while, whithout much success. It's weird that this one happens during insertion, instead of deletion.
Flags: needinfo?(emilio)
Updated•6 years ago
|
Flags: needinfo?(manishearth)
Comment 10•6 years ago
|
||
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.
Flags: needinfo?(manishearth)
Updated•2 years ago
|
Severity: critical → S2
Comment 11•2 years ago
|
||
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.)
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → WORKSFORME
Updated•2 years ago
|
Group: layout-core-security → core-security-release
Updated•1 year ago
|
Group: core-security-release
You need to log in
before you can comment on or make changes to this bug.
Description
•