Open Bug 1893909 Opened 1 year ago Updated 1 year ago

Crash in [@ core::option::unwrap_failed]

Categories

(Core :: CSS Parsing and Computation, defect)

ARM64
All
defect

Tracking

()

Tracking Status
firefox127 --- 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/5eaf120b-f611-4508-8d1c-58d720240411

MOZ_CRASH Reason: called `Option::unwrap()` on a `None` value

Top 10 frames of crashing thread:

0  xul.dll  MOZ_Crash  mfbt/Assertions.h:317
0  xul.dll  RustMozCrash  mozglue/static/rust/wrappers.cpp:17
1  xul.dll  mozglue_static::panic_hook  mozglue/static/rust/lib.rs:98
2  xul.dll  core::ops::function::Fn::call<void   /rustc/7cf61ebde7b22796c69757901dd346d0fe70bd97/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:785
4  xul.dll  std::panicking::begin_panic_handler::closure$0  library/std/src/panicking.rs:651
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:647
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-04-05
  • Process type: Multiple distinct types
  • Is startup crash: No
  • Has user comments: No
  • Is null crash: Yes - 5 out of 14 crashes happened on null or near null memory address

This signature is pretty useless, but the volume is so low I'm not sure it is worth adding this function to the prefix list.

Severity: -- → S3
Component: General → CSS Parsing and Computation
See Also: → 1899406

The bug is linked to a topcrash signature, which matches the following criterion:

  • Top 10 desktop browser crashes on nightly

:emilio, could you consider increasing the severity of this top-crash bug?

For more information, please visit BugBot documentation.

Flags: needinfo?(emilio)
Keywords: topcrash

This signature is not useful as is, it's a mixbag of style / webrender / etc crashes. Gabriele do you recall the process to add this to the skip list so that we can get more useful crash report aggregation?

Flags: needinfo?(emilio) → needinfo?(gsvelto)
Depends on: 1939976

I filed bug 1939976 and will handle it on Monday. The change does not happen immediately because Socorro needs to be updated first. I'll also take the time to look into how many signatures this is gonna blow up and preemptively file bugs for them.

Flags: needinfo?(gsvelto)

I'm adding what will become the most common signature once bug 1939976 goes into production. There will be no crashes under this signature until that happens, but when it does it will capture roughly 50% of these crashes.

Crash Signature: [@ core::option::unwrap_failed] → [@ core::option::unwrap_failed] [@ webrender_bindings::moz2d_renderer::impl$7::prepare_request::process_native_font_handle]
See Also: → 1940059
See Also: → 1940060
See Also: → 1940061

I've filed bugs for all the crash signatures that will split off from this one after bug 1939976 lands. Note that they all look like caused by bad hardware to me, but tracking them allows us to detect future spikes automatically in case something relevant comes up. There is a handful of new signatures for which I haven't filed bugs for because they only affected one or two crashes and also looked like bad hardware, so no point in tracking those.

Based on the topcrash criteria, the crash signatures linked to this bug are not in the topcrash signatures anymore.

For more information, please visit BugBot documentation.

Keywords: topcrash
You need to log in before you can comment on or make changes to this bug.