Crash in [@ NS_TableDrivenQI]
Categories
(Core :: XPCOM, defect)
Tracking
()
People
(Reporter: marcia, Unassigned)
References
Details
(Keywords: crash, Whiteboard: [startupcrash])
Crash Data
Comment 1•14 years ago
|
||
Updated•14 years ago
|
Comment 2•14 years ago
|
||
Reporter | ||
Updated•14 years ago
|
Comment 3•14 years ago
|
||
Assignee | ||
Updated•14 years ago
|
Updated•9 years ago
|
Comment 5•9 years ago
|
||
Comment 6•8 years ago
|
||
Comment 7•8 years ago
|
||
Comment 8•8 years ago
|
||
Comment 9•8 years ago
|
||
Comment 10•8 years ago
|
||
Comment 11•4 years ago
|
||
I doubt the bulk of crashes, few that they are (<90/week for Firefox), are actionable. bp-73534204-552a-4732-a98f-1ff910210220, 0 seconds, is an example.
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Updated•2 years ago
|
Comment 12•2 years ago
|
||
The bug is linked to a topcrash signature, which matches the following criterion:
- Top 10 AArch64 and ARM crashes on release (startup)
For more information, please visit auto_nag documentation.
Comment 13•2 years ago
|
||
This has spiked up, but it looks entirely due to a single installation that has crashes more than 400 times.
Here's one of those crashes: bp-7b6e4d72-b628-4ce8-b123-b2d900230404
The stack has nsInputStreamChannel::QueryInterface(), but not much else.
Comment 14•2 years ago
|
||
This seems unactionable, and like we should perhaps just add it to the prefix list.
Comment 15•2 years ago
|
||
Based on the topcrash criteria, the crash signature linked to this bug is not a topcrash signature anymore.
For more information, please visit auto_nag documentation.
Comment hidden (Intermittent Failures Robot) |
Description
•