MozillaWiki

CrashKill/Topcrash: Difference between revisions

Page Discussion

CrashKill/Topcrash (view source)

Revision as of 10:55, 8 June 2022

1 byte removed ,  8 June 2022
Much needed update
m (→‎Top crash identification criteria: clarify topcrash for Thunderbird Beta....)
(Much needed update)
Line 10: Line 10:
** Top 20 desktop browser crashes on Betas
** Top 20 desktop browser crashes on Betas
*** This should be pretty much the same as release. Where we see discrepancies are really around 3rd party issues which are important to call out for blocking candidates.
*** This should be pretty much the same as release. Where we see discrepancies are really around 3rd party issues which are important to call out for blocking candidates.
** Top 10 desktop browser crashes on Aurora and Nightly, if they happen for enough different installations.
** Top 10 desktop browser crashes on Nightly, if they happen for enough different installations.
*** This might need some experience and feeling for what issues are important.
*** This might need some experience and feeling for what issues are important.
** Top 10 plugin crashes on Beta and Release
** Top 10 content process crashes on Beta and Release
*** Hang signatures are pretty generic and non-actionable right now (improvements are being worked on), the crashes in that list need to be looked at more carefully.
** Top 5 gpu process crashes on Beta and Release
** Top 5 desktop browser crashes on Linux-, Mac-, and Win8- specific list on Beta and Release
** Top 5 rdd process crashes on Beta and Release
** Top 5 socket and utility process crashes on Beta and Release but only if they affect 5+ installations.
** Top 5 desktop browser crashes on Linux-, Mac-, and Win10- specific list on Beta and Release
*** If there's less than 5 crashes per week on a signature, that bug probably still doesn't qualify - same for crashes happening to only 2 or 3 installations.
*** If there's less than 5 crashes per week on a signature, that bug probably still doesn't qualify - same for crashes happening to only 2 or 3 installations.
*** If volume is very similar to the top 5, other bugs might still be included.
*** If volume is very similar to the top 5, other bugs might still be included.
*** High volume Win7- and Win8- crashes should also be considered if they affect a significant number of users.
** Hangs of various kinds are not always actionable so they probably shouldn't be flagged as top crashers unless their impact is significant.


* MetroFirefox:
* Fenix:
** TBD
** Top 10 AArch64- and ARM-crashes for Nightly, Beta and Release
 
** Top 5 AMD64- and x86- crashes for Beta and Release
* Firefox for Android:  
** Top 10 ARMv7-crashes for Nightly, Aurora, Beta and Release
** Top 5 ARMv6- and x86- crashes for Beta and Release
** Until we see plugins and addons that highly effect the stability of Firefox for Android, it may make sense to just stay at 10 for all channels.
 
* B2G:
** Top 5 crashes inside of what we have symbols for and support. For FxOS 1.0 & 1.1, they can be found in https://crash-stats.mozilla.com/query/query?product=B2G&version=B2G:18.0&do_query=1
*** If there's less than 5 crashes per week on a signature, that bug probably still doesn't qualify - same for crashes happening to only 2 or 3 installations.
*** Also note that only crashes on actual devices can count there, simulator/desktop crashes do not count as topcrashes unless they make the product practically unusable.


* Thunderbird:
* Thunderbird:
** Top 25 for Release
** Top 25 for Release
** Top 3 for Beta, Earlybird, Daily  
** Top 3 for Beta, Nightly  
*** Focus only on worst of the worse, and explosive crashes, and regressions because Aurora Beta and Daily rankings don't correlate well** to final releases. So assigning topcrash status normally doesn't help significantly reduce release topcrashes. (** Probably because the respective user populations and environments are significantly different.)
*** Focus only on worst of the worse, and explosive crashes, and regressions because Beta and Nightly rankings don't correlate well** to final releases. So assigning topcrash status normally doesn't help significantly reduce release topcrashes. (** Probably because the respective user populations and environments are significantly different.)


* Everything:
* Everything:
Line 41: Line 36:
** Crashes for actions that users are rarely taking, even if they are somewhat out of the usual topcrash ranges
** Crashes for actions that users are rarely taking, even if they are somewhat out of the usual topcrash ranges
*** This needs feeling and expertise as well, thing like that can be e.g. printing crashes in the top 50 on desktop release and similar cases.
*** This needs feeling and expertise as well, thing like that can be e.g. printing crashes in the top 50 on desktop release and similar cases.
* Crash signatures that should not be automatically considered top crashers even if high volume:
** All signatures starting with `EMPTY: ` or `OOM | large | EMPTY: ` (examples: `EMPTY: no crashing thread identified; HeaderMismatch` and `OOM | large | EMPTY: no crashing thread identified; StreamSizeMismatch`)
** `OOM | small`
** `IPCError-browser | ShutDownKill`
** Signatures starting with `java.lang.OutOfMemoryError` on Android
Gsvelto
Confirmed users
387

edits

Retrieved from "https://wiki.allizom.org/Special:MobileDiff/1242858"