Open Bug 1613797 Opened 4 months ago Updated 1 month ago

Crash in [@ IPCError-browser | ShutDownKill | hashglobe::hash_map::HashMap<T>::clear<T>]

Categories

(Core :: CSS Parsing and Computation, defect, P3)

Unspecified
Windows
defect

Tracking

()

People

(Reporter: mccr8, Unassigned)

References

Details

(Keywords: crash)

Crash Data

This bug is for crash report bp-23dbaa5d-d06c-467e-96d7-14d1b0200206.

Top 10 frames of crashing thread:

0 xul.dll hashglobe::hash_map::HashMap<style::gecko_string_cache::Atom, smallvec::SmallVec<[style::stylist::Rule; 1]>, core::hash::BuildHasherDefault<style::selector_map::PrecomputedHasher>>::clear<style::gecko_string_cache::Atom, smallvec::SmallVec<[style::stylist::Rule; 1]>, core::hash::BuildHasherDefault<style::selector_map::PrecomputedHasher>> servo/components/hashglobe/src/hash_map.rs:1079
1 xul.dll style::stylist::GenericElementAndPseudoRules<style::selector_map::SelectorMap<style::stylist::Rule>>::clear servo/components/style/stylist.rs:1705
2 xul.dll style::stylist::CascadeData::clear_cascade_data servo/components/style/stylist.rs:2241
3 xul.dll style::stylist::CascadeData::clear servo/components/style/stylist.rs:2259
4 xul.dll style::stylist::CascadeData::rebuild<style::gecko::data::GeckoStyleSheet> servo/components/style/stylist.rs:1844
5 xul.dll geckoservo::glue::Servo_StyleSet_FlushStyleSheets servo/ports/geckolib/glue.rs:1900
6 xul.dll mozilla::ServoStyleSet::UpdateStylist layout/style/ServoStyleSet.cpp:1128
7 xul.dll mozilla::ServoStyleSet::ShellDetachedFromDocument layout/style/ServoStyleSet.cpp:133
8 xul.dll mozilla::dom::Document::DeletePresShell dom/base/Document.cpp:6311
9 xul.dll mozilla::PresShell::Destroy layout/base/PresShell.cpp:1333

This signature is one of the more common ones, at least in the Nightly I looked at. In the crashes I skimmed, it was clearing Stylo data while destroying a pres shell.

Does the signature mean this is a shutdown hang? Or something else?

Flags: needinfo?(continuation)

Yes, I think that's what it means. Or at least, a hang while the process is shutting down.

Flags: needinfo?(continuation)

Yes, these aren't crashes. They're snapshots of content processes that were told to shut down but didn't succeed within a minute. When this happens we take a minidump of the content process, kill it and then submit the crash report. Note the mozilla::dom::BrowserChild::RecvDestroy() frame on the stack.

This seems to happen across all Windows versions.

OS: Windows 8 → Windows

I found another signature, all the crashes from the past six months have been reprocessed so this should now cover pretty much all of them.

Crash Signature: [@ IPCError-browser | ShutDownKill | hashglobe::hash_map::HashMap<T>::clear<T>] → [@ IPCError-browser | ShutDownKill | hashglobe::hash_map::HashMap<T>::clear<T>] [@ IPCError-browser | ShutDownKill | hashglobe::hash_map::HashMap<T>::clear]

Calling this P3, since it's presumably not an especially user-visible issue, given that we eventually clean up the hanging process.

Priority: -- → P3
Crash Signature: [@ IPCError-browser | ShutDownKill | hashglobe::hash_map::HashMap<T>::clear<T>] [@ IPCError-browser | ShutDownKill | hashglobe::hash_map::HashMap<T>::clear] → [@ IPCError-browser | ShutDownKill | hashglobe::hash_map::HashMap<T>::clear<T>] [@ IPCError-browser | ShutDownKill | hashglobe::hash_map::HashMap<T>::clear] [@ IPCError-browser | ShutDownKill | core::ptr::real_drop_in_place<T> | hashglobe::hash_map::Has…

This is showing up very high in the Nightly crash stats. Is there something we can do to improve the situation here?

Could we do something like not destroy this style data if we're shutting down? It'll be a little tricky because we do need to destroy it in debug builds for leak checking purposes. The stacks I've seen are inside mozilla::dom::BrowserChild::RecvDestroy() so it should be possible to detect.

Crash Signature: [@ IPCError-browser | ShutDownKill | hashglobe::hash_map::HashMap<T>::clear<T>] [@ IPCError-browser | ShutDownKill | hashglobe::hash_map::HashMap<T>::clear] [@ IPCError-browser | ShutDownKill | core::ptr::real_drop_in_place<T> | hashglobe::hash_map::Has… → [@ IPCError-browser | ShutDownKill | hashglobe::hash_map::HashMap<T>::clear<T>] [@ IPCError-browser | ShutDownKill | hashglobe::hash_set::HashSet<T>::clear<T> ] [@ IPCError-browser | ShutDownKill | hashglobe::hash_map::HashMap<T>::clear] [@ IPCError-br…

I added two more signatures that look like the same issue (synchronously destroying style data during shutdown).

Bugbug thinks this bug is a regression, but please revert this change in case of error.

Keywords: regression
Keywords: regression

Added a couple more signatures. We also have a corresponding shutdownhang entry (bug 1625835).

Crash Signature: [@ IPCError-browser | ShutDownKill | hashglobe::hash_map::HashMap<T>::clear<T>] [@ IPCError-browser | ShutDownKill | hashglobe::hash_set::HashSet<T>::clear<T> ] [@ IPCError-browser | ShutDownKill | hashglobe::hash_map::HashMap<T>::clear] [@ IPCError-br… → [@ IPCError-browser | ShutDownKill | arena_t::DallocSmall | Allocator<T>::free | replace_free | hashglobe::hash_map::HashMap<T>::clear<T>] [@ IPCError-browser | ShutDownKill | core::ptr::real_drop_in_place<T> | core::ptr::real_drop_in_place<T> | core::pt…
See Also: → 1625835
Duplicate of this bug: 1633334
Crash Signature: IPCError-browser | ShutDownKill | hashglobe::hash_map::HashMap<T>::clear] [@ IPCError-browser | ShutDownKill | hashglobe::hash_set::HashSet<T>::clear<T>] → IPCError-browser | ShutDownKill | hashglobe::hash_map::HashMap<T>::clear] [@ IPCError-browser | ShutDownKill | hashglobe::hash_set::HashSet<T>::clear<T>] [@ IPCError-browser | ShutDownKill | style::stylist::GenericElementAndPseudoRules<T>::clear]
You need to log in before you can comment on or make changes to this bug.