1475377 - Crash in static <T> core::result::unwrap_failed<T> | static union core::option::Option<T> style::gecko::wrapper::get_animation_rule

Status: RESOLVED WORKSFORME

(Core :: DOM: Animation, defect, P3)

Description

[[:philipp]]

This bug was filed from the Socorro interface and is
report bp-dba68289-d52a-47d1-8a54-b2b360180712.
=============================================================

Top 10 frames of crashing thread:

0 xul.dll static void std::panicking::rust_panic_with_hook src/libstd/panicking.rs:583
1 xul.dll static void std::panicking::begin_panic<alloc::string::String> src/libstd/panicking.rs:538
2 xul.dll static void std::panicking::begin_panic_fmt src/libstd/panicking.rs:522
3 xul.dll static void core::panicking::panic_fmt src/libcore/panicking.rs:70
4 xul.dll static <NoType> core::result::unwrap_failed<hashglobe::FailedAllocationError> src/libcore/macros.rs:23
5 xul.dll static union core::option::Option<servo_arc::Arc<style::shared_lock::Locked<style::properties::declaration_block::PropertyDeclarationBlock>>> style::gecko::wrapper::get_animation_rule servo/components/style/gecko/wrapper.rs:976
6 xul.dll static bool style::matching::PrivateMatchMethods::replace_rules_internal<style::gecko::wrapper::GeckoElement> servo/components/style/matching.rs:174
7 xul.dll static style::matching::ChildCascadeRequirement style::traversal::compute_style<style::gecko::wrapper::GeckoElement> servo/components/style/traversal.rs:704
8 xul.dll static void geckoservo::glue::traverse_subtree servo/ports/geckolib/glue.rs:292
9 xul.dll bool geckoservo::glue::Servo_TraverseSubtree servo/ports/geckolib/glue.rs:341

=============================================================

these reports are starting to show up in firefox 63.0a1 and since 62.0b6 - that's likely a signature shift from bug 1418806.

most of the crashes show the following moz_crash reason and are low on memory (not sure if that's cause or effect):
called `Result::unwrap()` on an `Err` value: FailedAllocationError { reason: "out of memory when allocating RawTable", allocation_info: Some(AllocationInfo { size: 8320, alignment: 4 }) }

Comment 1

[Hiroyuki Ikezoe (:hiro)]

I'd say it's a really out-of-memory caused by whatever reasons (I guess it's fragmentation).
Anyway, I did confirm that the size value '8320' is for a single animating property.  So I'd suggest to;


1) calculate exact number of animating properties before allocating the AnimationValueMap
2) introduce a new enum to avoid using the hash map for single property animations
 enum AnimationValueMap {
   Option<AnimationValue>,
   FnvHashMap<LonghandId, AnimationValue>,
 }

This should work and be less memory pressures, I think.

Comment 2

[Pascal Chevrel:pascalc (PTO until April 26)]

Long standing low volume crasher, we wouldn't take an uplift late in beta for this so marking wontfix for 67/68.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

Closing because no crashes reported for 12 weeks.