Open Bug 1880581 Opened 11 months ago Updated 7 months ago

Crash in [@ style::shared_lock::Locked<T>::read_with]

Categories

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

Other
All
defect

Tracking

()

Tracking Status
firefox124 --- affected

People

(Reporter: release-mgmt-account-bot, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: crash)

Crash Data

Crash report: https://crash-stats.mozilla.org/report/index/d17e336a-b787-4ad2-809c-8bc0e0240210

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

Top 10 frames of crashing thread:

0  xul.dll  MOZ_Crash  mfbt/Assertions.h:301
0  xul.dll  RustMozCrash  mozglue/static/rust/wrappers.cpp:17
1  xul.dll  mozglue_static::panic_hook  mozglue/static/rust/lib.rs:96
2  xul.dll  core::ops::function::Fn::call<void   /rustc/07dca489ac2d933c78d3c5158e3f43beefeb02ce/library/core/src/ops/function.rs:250
3  xul.dll  alloc::boxed::impl$49::call  library/alloc/src/boxed.rs:2029
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-01-08
  • Process type: Content
  • Is startup crash: No
  • Has user comments: No
  • Is null crash: Yes - 3 out of 4 crashes happened on null or near null memory address

The Bugbug bot thinks this bug should belong to the 'Core::CSS Parsing and Computation' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: General → CSS Parsing and Computation

Looks like the MOZ_CRASH invocation here was slightly-modified in bug 1731142, to include the pointer addresses. Adding see-also since this bug and that one share the same intentional-crash statement at least (not sure to-what-extent they're connected beyond that).

Emilio, could you take a look when you get a chance and set a severity & see if you see any hints here?

Looking at the "moz crash reason", I do see a handful of ones where the displayed addresses are odd (i.e. end in 1,3,5,7,9) putting them in the "totally bogus" category referenced in bug 1731142 comment 10; e.g. bp-0df82fc8-b5e1-4f41-86d7-62c540240212 says Locked::read_with called with a guard from an unrelated SharedRwLock: 0x11b67bdccf492953 vs. 0x1baa3cd4dc0

But most of them seem to have even addresses in the crash message (and aren't obvious bit-flips between the "vs" pointer-comparison values) so I'm not sure how much of the volume can be attributed to whatever corruption is producing the odd-valued addresses here.

Flags: needinfo?(emilio)
See Also: → 1731142

So, all the crashes in recent versions can be categorized as follows:

Obvious bit flips

I don't think it's worth digging into these.

Bizarre addresses

I took a look at these but nothing jumps out as weird.

Null address

This could indicate an issue on our font-face code perhaps?

Over all, given the volume, that this code is extremely hot, and that we literally just have one lock (we support multiple locks for servo, but Gecko just uses one), I don't think this should be particularly high severity.

Severity: -- → S3
Flags: needinfo?(emilio)
Priority: -- → P3
Duplicate of this bug: 1900507

Copying crash signatures from duplicate bugs.

Crash Signature: [@ style::shared_lock::Locked<T>::read_with] → [@ style::shared_lock::Locked<T>::read_with] [@ std::sys::pal::windows::abort_internal | std::process::abort | servo_arc::impl$10::clone]
You need to log in before you can comment on or make changes to this bug.