OLD | NEW |
---|---|
1 Look for new crashers: | |
2 * Go to go/chromecrash. | |
3 * Choose the platforms and releases for which you will be | |
4 investigating crashers. As per bug-triage.txt, this should be the | |
5 most recent canary, the previous canary (if the most recent is less | |
6 than a day old), and any of dev/beta/stable that were released in the | |
7 last couple of days. These releases should be investigated for all | |
8 platforms. | |
9 * For each release, in the "Process Type" frame, click on "browser". | |
10 * At the bottom of the "Magic Signature" frame, click "limit 1000". | |
11 Reported crashers are sorted in decreasing order of the number of reports for | |
12 that crash signature. | |
13 * Search the page for "net::". | |
14 * For each found signature: | |
15 * If there is a bug already filed, make sure it is correctly | |
16 describing the current bug (e.g. not closed, or not describing a | |
17 long-past issue). If there is a valid associated bug, ignore this | |
18 signature. | |
19 * Ignore signatures that only occur once, as memory corruption can | |
20 easily cause one-off failures when the sample size is large | |
21 enough. | |
22 * Ignore signatures that only come from a single client ID, as | |
23 individual machine malware and breakage can also easily cause | |
24 one-off failures. | |
25 * Click on the number of reports field to see details of | |
26 crash. Ignore it if it doesn't appear to be a network bug. | |
27 * Otherwise, file a new bug directly from chromecrash. Note that | |
28 this may result in filing bugs for low- and very-low- frequency | |
29 crashes. That's ok; the bug tracker is a better tool to figure | |
30 out whether or not we put resources into those crashes than a snap | |
31 judgement when filing bugs. | |
Ryan Sleevi
2015/03/02 19:01:09
There is more needed here - for example, examining
mmenke
2015/03/02 19:15:13
I'd take issue with "high quality signal/noise fil
Randy Smith (Not in Mondays)
2015/03/03 15:08:01
So I thought about doing that, but I have no clue
Randy Smith (Not in Mondays)
2015/03/03 15:08:02
Acknowledged.
| |
32 * For each bug you file, include the following information: | |
33 * The backtrace | |
Ryan Sleevi
2015/03/02 19:01:09
Do not do this unless you've confirmed with the TP
Randy Smith (Not in Mondays)
2015/03/03 15:08:01
Conversation in process.
Randy Smith (Not in Mondays)
2015/03/04 22:22:21
Refined contexts under which adding a backtrace is
| |
34 * The channel in which the bug is seen (canary/dev/beta/stable) and | |
35 its frequency in that channel. | |
36 * The frequency of this signature in recent releases. This | |
37 information is available by: | |
38 * Clicking on the signature in the "Magic Signature" list | |
39 * Clicking "Edit" on the dremel query at the top of the page | |
40 * Removing the "product.version='X.Y.Z.W' AND" string and clicking | |
41 "Update". | |
42 * Clicking "Limit 1000" in the Product Version list in the | |
43 resulting page (without this, the listing will be restricted to | |
44 the releases in which the signature is most common, which will | |
45 often not include the canary/dev release being investigated). | |
46 * Choose some subset of that list, or all of it, to include in the | |
47 bug. Make sure to indicate if there is a defined point in the | |
48 past before which the signature is not present. | |
49 | |
Ryan Sleevi
2015/03/02 19:01:09
Please run these last two steps by the TPMs.
Randy Smith (Not in Mondays)
2015/03/03 15:08:02
These steps are ok by them (laforge@ specifically)
| |
1 Identifying unlabeled network bugs on the tracker: | 50 Identifying unlabeled network bugs on the tracker: |
2 * Look at new uncomfirmed bugs since noon PST on the last triager's rotation: | 51 * Look at new uncomfirmed bugs since noon PST on the last triager's rotation: |
3 https://code.google.com/p/chromium/issues/list?can=2&q=status%3Aunconfirmed& sort=-id&num=1000 | 52 https://code.google.com/p/chromium/issues/list?can=2&q=status%3Aunconfirmed& sort=-id&num=1000 |
4 * Press "h" to bring up a preview of the bug text. | 53 * Press "h" to bring up a preview of the bug text. |
5 * Use "j" and "k" to advance through bugs. | 54 * Use "j" and "k" to advance through bugs. |
6 * If a bug looks like it might be network/download/safe-browsing related, middle | 55 * If a bug looks like it might be network/download/safe-browsing related, middle |
7 click [or command-click on OSX] to open in new tab. | 56 click [or command-click on OSX] to open in new tab. |
8 * If a user provides a crash ID for a crasher for a bug that could be | 57 * If a user provides a crash ID for a crasher for a bug that could be |
9 net-related, look at the crash stack at go/crash, and see if it looks to be | 58 net-related, look at the crash stack at go/crash, and see if it looks to be |
10 network related. Be sure to check if other bug reports have that stack | 59 network related. Be sure to check if other bug reports have that stack |
11 trace, and mark as a dupe if so. Even if the bug isn't network related, | 60 trace, and mark as a dupe if so. Even if the bug isn't network related, |
12 paste the stack trace in the bug, so no one else has to look up the crash | 61 paste the stack trace in the bug, so no one else has to look up the crash |
13 stack from the ID. | 62 stack from the ID. |
14 * If there's no other information than the crash ID, ask for more details and | 63 * If there's no other information than the crash ID, ask for more details and |
15 add the Needs-Feedback label. | 64 add the Needs-Feedback label. |
16 * If network causes are possible, ask for a net-internals log (If it's not a | 65 * If network causes are possible, ask for a net-internals log (If it's not a |
17 browser crash) and attach the most specific internals-network label that's | 66 browser crash) and attach the most specific internals-network label that's |
18 applicable. If there isn't an applicable narrower label, a clear owner for | 67 applicable. If there isn't an applicable narrower label, a clear owner for |
19 the issue, or there are multiple possibilities, attach the internals-network | 68 the issue, or there are multiple possibilities, attach the internals-network |
20 label and proceed with further investigation. | 69 label and proceed with further investigation. |
21 * If non-network causes also seem possible, attach those labels as well. | 70 * If non-network causes also seem possible, attach those labels as well. |
22 | 71 |
72 Request data about recent unassigned Cr-Internals-Network bugs from reporters. | |
73 * For all bugs in this category marked "Needs-Feedback", go through | |
74 them and remove that label if the reporter has responded with the | |
75 requested information. | |
76 * For all bugs in this category not marked "Needs-Feedback", go | |
77 through those bugs and determine if more information is needed from | |
78 the reporter to make forward progress on the bug. IF it is, request | |
mmenke
2015/03/02 19:15:13
nit: IF -> If
Randy Smith (Not in Mondays)
2015/03/03 15:08:02
Done.
| |
79 that information and mark the bug Needs-Feedback. | |
80 | |
23 Investigating Cr-Internals-Network bugs: | 81 Investigating Cr-Internals-Network bugs: |
24 * It's recommended that while on triage duty, you subscribe to the | 82 * It's recommended that while on triage duty, you subscribe to the |
25 Cr-Internals-Network label. To do this, go to | 83 Cr-Internals-Network label. To do this, go to |
26 https://code.google.com/p/chromium/issues/ and click on "Subscriptions". | 84 https://code.google.com/p/chromium/issues/ and click on "Subscriptions". |
27 Enter Cr-Internals-Network and click submit. | 85 Enter Cr-Internals-Network and click submit. |
28 * Look through uncomfirmed and untriaged Cr-Internals-Network bugs, prioritizing | 86 * Look through uncomfirmed and untriaged Cr-Internals-Network bugs, prioritizing |
29 those updated within the last week: | 87 those updated within the last week: |
30 https://code.google.com/p/chromium/issues/list?can=2&q=Cr%3DInternals-Networ k+-status%3AAssigned+-status%3AStarted+-status%3AAvailable+&sort=-modified | 88 https://code.google.com/p/chromium/issues/list?can=2&q=Cr%3DInternals-Networ k+-status%3AAssigned+-status%3AStarted+-status%3AAvailable+&sort=-modified |
31 * While investigating a new issue, change the status to Untriaged. | 89 * While investigating a new issue, change the status to Untriaged. |
32 * If a bug is a potential security issue (Allows for code execution from remote | 90 * If a bug is a potential security issue (Allows for code execution from remote |
(...skipping 35 matching lines...) Expand 10 before | Expand all | Expand 10 after Loading... | |
68 strongly suspect CLs. | 126 strongly suspect CLs. |
69 * If you are having trouble with an issue, particularly for help understanding | 127 * If you are having trouble with an issue, particularly for help understanding |
70 net-internals logs, email the public net-dev@chromium.org list for help | 128 net-internals logs, email the public net-dev@chromium.org list for help |
71 debugging. If it's a crasher, or for some other reason discussion needs to | 129 debugging. If it's a crasher, or for some other reason discussion needs to |
72 be done in private, use chrome-network-debugging@google.com. | 130 be done in private, use chrome-network-debugging@google.com. |
73 TODO(mmenke): Write up a net-internals tips and tricks docs. | 131 TODO(mmenke): Write up a net-internals tips and tricks docs. |
74 * If it appears to be a bug in the unowned core of the network stack (i.e. no | 132 * If it appears to be a bug in the unowned core of the network stack (i.e. no |
75 sublabel applies, or only the Cr-Internals-Network-HTTP sublabel applies, | 133 sublabel applies, or only the Cr-Internals-Network-HTTP sublabel applies, |
76 and there's no clear owner), try to figure out the exact cause. | 134 and there's no clear owner), try to figure out the exact cause. |
77 | 135 |
78 Look for new crashers: | 136 Monitor UMA histograms and gasper alerts. For each Gasper alert that |
79 * Go to go/chromecrash. | 137 fires, determine if it's a real alert and file a bug if so. |
80 * For each platform, go to the latest canary. | 138 * Don't file if the alert is coincident with a major volume change. |
81 * In the "Process Type" frame, click on "browser". | 139 The volume at a particular date can be determined by hovering the |
82 * At the bottom of the "Magic Signature" frame, click "limit 1000". | 140 mouse over the appropriate location on the alert line. |
83 Reported crashers are sorted in decreasing order of the number of reports for | 141 * Don't file if the alert is on a graph with very low volume (< ~200 |
84 that crash signature. | 142 data points); it's probably noise, and we probably don't care even |
85 * Search the page for "net::". Ignore crashes that only occur once, as | 143 if it isn't. |
86 memory corruption can easily cause one-off failures when the sample size is | 144 * Don't file if the graph is really noisy (but eyeball it to decide if |
87 large enough. | 145 there is an underlying important shift under the noise). |
88 * Click on the number of reports field to see details of crash. Look at the | 146 * Don't file if the alert is in the "Known Ignorable" list: |
89 stack trace to confirm it's a network bug. | 147 * SimpleCache on Windows |
90 * If it is, and there's no associated bug filed, file a new bug directly from | 148 * DiskCache on Android. |
91 chromecrash, looking at earlier canaries to determine if it's a recent | 149 For each Gasper alert, respond to chrome-network-debugging@ with a |
92 regression. Use the most specific label possible. | 150 summary of the action you've taken and why, including issue link if an |
93 * The most recent Canary may not yet have a full day of crashes, so it may be | 151 issue was filed. |
94 worth looking at more than one version. | |
95 * If there's been a dev, beta, or stable release in the last couple days, should | |
96 also look at those. | |
97 | 152 |
98 Investigating crashers: | 153 Investigating crashers: |
99 * Only investigate crashers that are still occurring, as identified by above | 154 * Only investigate crashers that are still occurring, as identified by above |
100 section. If a search on go/crash indicates a crasher is no longer | 155 section. If a search on go/crash indicates a crasher is no longer |
101 occurring, mark it as WontFix. | 156 occurring, mark it as WontFix. |
102 * Particularly for Windows, look for weird dlls associated with the crashes. | 157 * Particularly for Windows, look for weird dlls associated with the crashes. |
103 If there are some, it may be caused by malware. You can often figure out if | 158 If there are some, it may be caused by malware. You can often figure out if |
104 a dll is malware by a search, though it's harder to figure out if a dll is | 159 a dll is malware by a search, though it's harder to figure out if a dll is |
105 definitively not malware. | 160 definitively not malware. |
106 * See if the same users are repeatedly running into the same issue. This can be | 161 * See if the same users are repeatedly running into the same issue. This can be |
(...skipping 17 matching lines...) Expand all Loading... | |
124 * If a bug is over 2 months old, and the underlying problem was never | 179 * If a bug is over 2 months old, and the underlying problem was never |
125 reproduced or really understood: | 180 reproduced or really understood: |
126 * If it's over a year old, go ahead and mark the issue as Archived. | 181 * If it's over a year old, go ahead and mark the issue as Archived. |
127 * Otherwise, ask reporters if the issue is still present, and attach the | 182 * Otherwise, ask reporters if the issue is still present, and attach the |
128 Needs-Feedback label. | 183 Needs-Feedback label. |
129 * Old unconfirmed or untriaged Cr-Internals-Network issues can be investigated | 184 * Old unconfirmed or untriaged Cr-Internals-Network issues can be investigated |
130 just like newer ones. Crashers should generally be given higher priority, | 185 just like newer ones. Crashers should generally be given higher priority, |
131 since we can verify if they still occur, and then newer issues, as they're | 186 since we can verify if they still occur, and then newer issues, as they're |
132 more likely to still be present, and more likely to have a still responsive | 187 more likely to still be present, and more likely to have a still responsive |
133 bug reporter. | 188 bug reporter. |
OLD | NEW |