1900507 - Crash in [@ std::sys::pal::windows::abort_internal | std::process::abort | servo_arc::impl$10::clone]

Status: RESOLVED DUPLICATE of bug 1880581

(Core :: CSS Parsing and Computation, defect)

Description

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

Crash report: https://crash-stats.mozilla.org/report/index/ebd94dba-a350-4dc1-8138-0d0460240602

MOZ_CRASH Reason: Locked::read_with called with a guard from an unrelated SharedRwLock: 0xfff5f5f9fff5f609 vs. 0x25b7f689cc0

Top 10 frames of crashing thread:

0  xul.dll  MOZ_Crash  mfbt/Assertions.h:317
0  xul.dll  RustMozCrash  mozglue/static/rust/wrappers.cpp:18
1  xul.dll  mozglue_static::panic_hook  mozglue/static/rust/lib.rs:98
2  xul.dll  core::ops::function::Fn::call<void   /rustc/9b00956e56009bab2aa15d7bff10916599e3d6d6/library/core/src/ops/function.rs:250
3  xul.dll  alloc::boxed::impl$49::call  library/alloc/src/boxed.rs:2034
3  xul.dll  std::panicking::rust_panic_with_hook  library/std/src/panicking.rs:783
4  xul.dll  std::panicking::begin_panic_handler::closure$0  library/std/src/panicking.rs:657
5  xul.dll  std::sys_common::backtrace::__rust_end_short_backtrace<std::panicking::begin_panic_handler::closure_env$0, never$>  library/std/src/sys_common/backtrace.rs:171
6  xul.dll  std::panicking::begin_panic_handler  library/std/src/panicking.rs:645
7  xul.dll  core::panicking::panic_fmt  library/core/src/panicking.rs:72

By querying Nightly crashes reported within the last 2 months, here are some insights about the signature:

• First crash report: 2024-06-02
• Process type: Multiple distinct types
• Is startup crash: No
• Has user comments: No
• Is null crash: No

By analyzing the backtrace, the regression may have been introduced by a patch [1] to fix Bug 1886441.

[1] https://hg.mozilla.org/mozilla-central/rev?node=ca2516594d77

:dshin, since you are the author of the potential regressor, could you please take a look?

Comment 1

[David Shin[:dshin]]

Similar crash signatures, other than in comment 0:

• https://crash-stats.mozilla.org/report/index/46d733a1-2bb8-41e6-ae24-b305e0240603 (Almost the same trace, also Win 11)
• https://crash-stats.mozilla.org/report/index/e594e888-c8ba-4f64-b71b-38d640240530 (Different looking trace, Win 10)

The recorded crash reason does not seem correct ("Locked::read_with called with a guard from an unrelated SharedRwLock: 0xfff5f5f9fff5f609 vs. 0x25b7f689cc0"), I don't see how process::abort() can hit the crash message from here.

As for the actual crash - it's telling me that the selector has too big of a refcount. Bug 1886441 is a big change that touches Stylist, and it generates additional style rules under within the @scope block (As well as selectors specifying scope bounds, but those wouldn't interact with revalidation selector map at all), but I don't see how that'd cause cloning arc enough to trigger this..

Comment 2

[Emilio Cobos Álvarez (:emilio)]

0xfff5f5f9fff5f609

That pointer can't be right can it?

Comment 3

[Emilio Cobos Álvarez (:emilio)]

In the past, every time we've seen this signature it is bad hardware.

Comment 4

[Emilio Cobos Álvarez (:emilio)]

(If only because we use just one global RWLock for Gecko)

Comment 5

[David Shin[:dshin]]

(In reply to Emilio Cobos Álvarez (:emilio) from comment #2)

0xfff5f5f9fff5f609

That pointer can't be right can it?

Agreed - the reported MOZ_CRASH signature makes it look like bug 1880581, but I'm not sure how that message falls out of process::abort().

Comment 6

[Emilio Cobos Álvarez (:emilio)]

This is probably just bug 1880581 indeed. Maybe a Windows signature change?