CrashKill/Mobile Process
From MozillaWiki
There are a lot of things that are done in regards to trying to find crash bugs, report crash bugs, and process crash bugs. Some take a lot of time and specialization; others are a matter of going through some easy steps.
Listed are some of the more generic things that you can do to help contribute and make sure that bugs get fixed in various channels.
Release
- Generally we want to catch really high crashing bugs before this goes out the main audience.
- In order to do this, we want to make sure that the top crashers in beta are fixed.
- After it hits release, we want to monitor the top crash for the released version :
https://crash-stats.mozilla.com/topcrasher/products/FennecAndroid/versions/<release version> current release version is 22.0 at the time this was written so you would want to go to : https://crash-stats.mozilla.com/topcrasher/products/FennecAndroid/versions/22.0
- after reporting the bug, make sure that you:
- list the crash in the crash signature field
- list the devices
- list the Android OS version
- Triaging bugs:
- make sure that the top 10 of each channel (release, beta, aurora, nightly) are marked [native-crash] and topcrash
- verify that the topcrash list is correct by looking at all the top crashes in a certain channel and make sure to update with a comment stating what position the crash is in : topcrashlist
- some crashes have multiple signatures. Update the crash signature field with matching crash signatures.
Beta
- Finding bugs that are fixed in nightly but not in beta, revolves around going to the Nightly top crasher versions and seeing what's been crossed out (fixed)
- take a look in those crossed out bugs, and check to see if it's been pushed to beta.
- do the same for aurora... look in the top crasher list and see what's been pushed to beta.
- note: be careful and make sure that it is affecting beta before you ask for a nom, or ask for it to get pushed to beta.
- some things that will help with processing are looking at kairo's reports https://crash-analysis.mozilla.com/rkaiser/0000.overview.html#latest:
- looking at the beta explosive report also will help, to see what might need to be reported due to it being a top crash riser all the sudden : https://crash-analysis.mozilla.com/rkaiser/2012-09-23/2012-09-23.fennecandroid.nightly.explosiveness.html
- getting the devices affected : ex. https://crash-analysis.mozilla.com/rkaiser/2012-09-23/2012-09-23.fennec.nightly.devices.weekly.html
- some crash signatures might be aggregated, looking at the components may help : ex https://crash-analysis.mozilla.com/rkaiser/2012-09-23/2012-09-23.fennecandroid.nightly.components.weekly.html
- You'll want to make sure how high the crash is on the chart : https://crash-stats.mozilla.com/topcrasher/products/FennecAndroid/versions/23.0b2
- If there's steps to repro, please list them
- If there's URLs that you can see after logging in to Socorro, please list them (minus any adult sites please)
- If you happen to know what Android OS version or type it is : ie 2.2 (froyo), 2.3 (gingerbread), 3.x (honeycomb), 4.0 (ice cream sandwich), 4.1 (jelly bean), 4.2 (jelly bean) or if it's a custom kernel such as cynogenmod
- If it happens to deal with a hardware keyboard or software keyboard, please list that information.
- when looking at a crash, a useful crash will contain information in the source column.
Aurora
- same thing as beta, but you're looking only for fixed in the nightly crash reports and aurora for the top crashing bugs.
Nightly
- Just looking at nightly reports...
- basically a lot of seeing how high certain things spike and making sure new top bugs are reported.
- Specialized stuff would be to look at stack frames, and try to figure out repro steps based on frames, url, and any other clues such as OS, device, etc.