1800304 - Crash in [@ style::shared_lock::SharedRwLock::read]

Status: RESOLVED WORKSFORME

(Core :: CSS Parsing and Computation, defect)

Description

[Gabriele Svelto [:gsvelto]]

Crash report: https://crash-stats.mozilla.org/report/index/dc98f3de-86cb-4f2a-afcd-886f60221111

MOZ_CRASH Reason: already mutably borrowed

Top 10 frames of crashing thread:

0  libxul.so  RustMozCrash  mozglue/static/rust/wrappers.cpp:18
1  libxul.so  mozglue_static::panic_hook  mozglue/static/rust/lib.rs:91
2  libxul.so  core::ops::function::Fn::call  library/core/src/ops/function.rs:77
3  libxul.so  std::panicking::rust_panic_with_hook  library/std/src/panicking.rs:702
4  libxul.so  std::panicking::begin_panic_handler::{{closure}}  library/std/src/panicking.rs:588
5  libxul.so  std::sys_common::backtrace::__rust_end_short_backtrace  library/std/src/sys_common/backtrace.rs:138
6  libxul.so  rust_begin_unwind  library/std/src/panicking.rs:584
7  libxul.so  core::panicking::panic_fmt  library/core/src/panicking.rs:142
8  libxul.so  core::panicking::panic_display  library/core/src/panicking.rs:72
9  libxul.so  style::shared_lock::SharedRwLock::read  servo/components/style/shared_lock.rs:124

These crash signatures aren't great and I fear there might be different crashes lurking under them. This stack seems the most common though.

Comment 1

[Jonathan Kew [:jfkthame]]

Interestingly, this seems to start spiking around Sept 23rd, while the very similar-looking bug 1800306 doesn't go up until a month later. Which feels like it could indicate multiple issues that are manifesting as this kind of crash.

Marking as S3 for now -- crash volume is holding steady, but without STR it may be difficult to get to the root of this. (Maybe the fuzzers will get lucky and find a testcase for us...?)

Comment 2

[Daniel Holbert [:dholbert]]

If we're grouping multiple signatures together, the [@ atomic_refcell::AtomicRefCell<T>::borrow_mut ] signature probably is more appropriately grouped with bug 1800306 rather than with this bug.

Comment 3

[Daniel Holbert [:dholbert]]

With that change (removing that signature), the graph shows that the crash volume under the remaining signature (from comment 0's crash) -- [@ style::shared_lock::SharedRwLock::read ] -- seems to have been a spike in October, which is now mostly gone.

It had >50 crashes per day for most of October, peaking at ~83 crashes/day. But it's had single digit crashes per day from October 26th until now -- i.e. 6 weeks -- aside from a small spike to 17 crashes on Dec 3 (which were for Fenix 105, i.e. an out-of-date release).

Comment 4

[Daniel Holbert [:dholbert]]

Aggregating the last 6 months of crash data on Major Version, it looks like:

• 98.23 % of the crashes are for version 105
• The remaining crashes are nearly all for versions 104 (0.86%) and 106 (0.76%)
• And there was a single crash report for v101 and v103

But notably, no crashes reported for any versions newer than 106.

So I think we can consider this one ([@ style::shared_lock::SharedRwLock::read ]) to be WORKSFORME in 107 and newer.

--> Closing as such, and unsetting the "Affected" flags for those versions. (I suppose we could flag those versions as "Fixed" but I'm uneasy doing that without knowing what fixed it.)