Crash in [@ core::option::unwrap_failed]
Categories
(Core :: CSS Parsing and Computation, 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
Comment 1•1 year ago
|
||
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.
Updated•1 year ago
|
| Reporter | ||
Comment 2•1 year ago
|
||
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.
Comment 3•1 year ago
|
||
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?
Comment 4•1 year ago
|
||
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.
Comment 5•1 year ago
|
||
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.
Comment 6•1 year ago
|
||
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.
| Reporter | ||
Comment 7•1 year ago
|
||
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.
Description
•