1451043 - Crash in static struct style::rule_tree::StrongRuleNode style::rule_tree::RuleTree::compute_rule_node

Status: RESOLVED DUPLICATE of bug 1439440

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

Description

[Marcia Knous [:marcia]]

This bug was filed from the Socorro interface and is
report bp-fb499f70-b34d-4634-ad70-757d50180403.
=============================================================

Seen while looking at nighty crash data: https://bit.ly/2q2glbf. Windows 7 crash that has similar signature to Bug 1439440.

Top 10 frames of crashing thread:

0 xul.dll static struct style::rule_tree::StrongRuleNode style::rule_tree::RuleTree::compute_rule_node servo/components/style/rule_tree/mod.rs:289
1 xul.dll static struct style::style_resolver::MatchingResults style::style_resolver::StyleResolverForElement<style::gecko::wrapper::GeckoElement>::match_primary<style::gecko::wrapper::GeckoElement> servo/components/style/style_resolver.rs:454
2 xul.dll static struct style::style_resolver::ResolvedElementStyles style::style_resolver::StyleResolverForElement<style::gecko::wrapper::GeckoElement>::resolve_style<style::gecko::wrapper::GeckoElement> servo/components/style/style_resolver.rs:230
3 xul.dll static style::matching::ChildCascadeRequirement style::traversal::compute_style<style::gecko::wrapper::GeckoElement> servo/components/style/traversal.rs:611
4 xul.dll static void rayon_core::job::{{impl}}::execute<closure> third_party/rust/rayon-core/src/job.rs:156
5 xul.dll static void rayon_core::registry::WorkerThread::wait_until_cold<rayon_core::latch::CountLatch> third_party/rust/rayon-core/src/registry.rs:567
6 xul.dll static void std::sys_common::backtrace::__rust_begin_short_backtrace<closure,  src/libstd/sys_common/backtrace.rs:137
7 xul.dll static void alloc::boxed::{{impl}}::call_box< src/liballoc/boxed.rs:788
8 xul.dll static void std::sys::windows::thread::{{impl}}::new::thread_start src/libstd/sys/windows/thread.rs:55
9 kernel32.dll BaseThreadInitThunk 

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

Comment 1

[Maire Reavy [:mreavy]]

Emilio - is this a signature change from Bug 1439440?  Seems likely.  If so, we should dup it and update the signature on the other bug.  Is there any chance this is actionable?  Most of the crashes seem to be null derefs; was your comment on the other bug about the null-derefs, or the less-frequent rust panics?  Thanks

Comment 2

[Emilio Cobos Álvarez (:emilio)]

(In reply to Maire Reavy [:mreavy] Plz needinfo? from comment #1)
> Emilio - is this a signature change from Bug 1439440?  Seems likely.

Yes

> If so, we should dup it and update the signature on the other bug.

> Is there any chance this is actionable?  Most of the crashes seem to be null derefs; was
> your comment on the other bug about the null-derefs, or the less-frequent rust panics?

I was talking about the panics. Those panics should be literally impossible, since we use a single lock. So some sort of external memory corruption needs to be happening for those.

Took a look at the null derefs and it looks it's surprisingly frequent in AMD CPUs... Which makes me think it's somewhat possible that it's an AMD bug related to memory synchronization. I commented on the bug.

If it's not that I'm out of ideas, just double-checked the code and there's nothing particularly fishy about it (I wrote that so I could be biased / blind though...).

Given that I'd say not actionable unfortunately :/.