Skip to content

GitLab

T
tangled
Commit ae32850c authored by Matt Menke's avatar Matt Menke Committed by Commit Bot
Browse files
Options

Update network triage docs. 

In particular, replace about:net-internals with
chrome://net-export, add link to end-user instructions to
chrome://net-export itself, add a link to internal chrome network
crash page, and slightly update instructions.

Bug: None
Change-Id: I8ce872f1874ca632c7a1417fb9727fe4e4131778
Reviewed-on: https://chromium-review.googlesource.com/964943
Commit-Queue: Matt Menke <mmenke@chromium.org>
Reviewed-by: default avatarEric Roman <eroman@chromium.org>
Cr-Commit-Position: refs/heads/master@{#544402}
parent cb23db0f
Hide whitespace changes
Inline Side-by-side
Showing with 49 additions and 44 deletions
components/net_log/resources/net_export.html
View file @ ae32850c
......@@ -44,6 +44,9 @@
<div class="section-container">
Click the button to start logging future network activity to a file on
disk.
<a href="https://dev.chromium.org/for-testers/providing-network-details"
target="_blank">
See the Chromium website for more detailed instructions.</a>
</div>
<div class="outline-box">
......
net/docs/bug-triage-suggested-workflow.md
View file @ ae32850c
......@@ -21,7 +21,7 @@
trace in the bug, so no one else has to look up the crash stack from the ID.
* If there's just a blank form and a crash ID, just ignore the bug.
* If network causes are possible, ask for a net-internals log (If it's not a
* If network causes are possible, ask for a net-export log (If it's not a
browser crash) and attach the most specific internals-network label that's
applicable. If there isn't an applicable narrower component, a clear owner
for the issue, or there are multiple possibilities, attach the
......@@ -50,7 +50,7 @@ For each alert that fires, determine if it's a real alert and file a bug if so.
## Investigating component=Internals>Network bugs
* Note that you may want to investigate Needs-Feedback bugs first, as
that may result in some bugs being added to this list.
that may result in some bugs being added to this list.
* It's recommended that while on triage duty, you subscribe to the
Internals>Network component (but not its subcomponents). To do this, go
......@@ -90,7 +90,7 @@ For each alert that fires, determine if it's a real alert and file a bug if so.
* If it may be a network bug, attach additional possibly relevant component if
any, and continue investigating. Once you either determine it's a
non-network bug, or figure out accurate more specific network components, your
job is done, though you should still ask for a net-internals dump if it seems
job is done, though you should still ask for a net-export dump if it seems
likely to be useful.
* Note that Chrome-OS-specific network-related code (Captive portal detection,
......@@ -105,11 +105,10 @@ For each alert that fires, determine if it's a real alert and file a bug if so.
user.
* Try to reproduce locally. If you can, and it's a regression, use
src/tools/bisect-builds.py to figure out when it regressed.
* Ask more data from the user as needed (net-internals dumps, repro case,
crash ID from about:crashes, run tests, etc).
* If asking for an about:net-internals dump, provide this link:
* Ask more data from the user as needed (net-export dumps, repro case,
crash ID from chrome://crashes, run tests, etc).
* If asking for a chrome://net-export dump, provide this link:
https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details.
Can just grab the link from about:net-internals, as needed.
* Try to figure out what's going on, and which more specific network component
is most appropriate.
......@@ -119,10 +118,9 @@ For each alert that fires, determine if it's a real alert and file a bug if so.
strongly suspect CLs.
* If you are having trouble with an issue, particularly for help understanding
net-internals logs, email the public net-dev@chromium.org list for help
net-export logs, email the public net-dev@chromium.org list for help
debugging. If it's a crasher, or for some other reason discussion needs to
be done in private, use chrome-network-debugging@google.com. TODO(mmenke):
Write up a net-internals tips and tricks docs.
be done in private, use chrome-network-debugging@google.com.
* If it appears to be a bug in the unowned core of the network stack (i.e. no
subcomponent applies, or only the Internals>Network>HTTP subcomponent
......@@ -184,7 +182,7 @@ As an alternative to the above, you can use [Eric Roman's new crash
tool](https://ericroman.users.x20web.corp.google.com/www/net-crash-triage/index.html)
(internal link). Note that it isn't a perfect fit with the triage
responsibilities, specifically:
* It's only showing Windows releases; Android, iOS, and WebView are
usually different, and Mac is sometimes different.
* The instructions are to look at the latest canary which has a days
......@@ -192,7 +190,7 @@ responsibilities, specifically:
than one canary into the past, and hence not visible on the tool.
* Eric's tool filters based on files in "src/net" rather than looking
for magic signature's including the string "net::" ("src/net" is
probably the better filter).
probably the better filter).
## Investigating crashers
......
net/docs/bug-triage.md
View file @ ae32850c
......@@ -30,20 +30,20 @@ uniform, predictable two day commitment for all triagers.
### Required:
* Identify new network bugs on the bug tracker. All Unconfirmed issues filed
during your triage rotation should be scanned, and, for suspected network
bugs, a network component assigned and an about:net-internals log requested.
A triager is responsible for looking at bugs reported from noon PST / 3:00 pm
EST of the last day of the previous triager's rotation until the same time on
the last day of their rotation. Once you've assigned a bug to a component,
mark it Untriaged, so other triagers sorting through Unconfirmed bugs won't
see it.
* For desktop bugs, ask for a net-internals log and give the user a link to
https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details
(A link there appears on about:net-internals, for easy reference) for
instructions. On mobile, point them to about:net-export. In either case,
attach the Needs-Feedback label.
* Identify new network bugs on the bug tracker, looking at [this issue tracker
query](https://bugs.chromium.org/p/chromium/issues/list?q=status%3Aunconfirmed&sort=-id&num=1000).
* All Unconfirmed issues filed during your triage rotation should be scanned,
and, for suspected network bugs, a network component assigned and a
chrome://net-export/ log requested. Suggested text: "Please collect and
attach a chrome://net-export log. Instructions can be found here:
https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details".
A link to the instructions appears on net-export, for easy reference.
When asking for a log or more details, attach the Needs-Feedback label.
* A triager is responsible for looking at bugs reported from noon PST /
3:00 pm EST of the last day of the previous triager's rotation until the
same time on the last day of their rotation.
* Investigate UMA notifications.
......@@ -51,17 +51,17 @@ uniform, predictable two day commitment for all triagers.
sent to chrome-network-debugging@google.com. Triagers should subscribe
to this list. When an alert fires, the triager should determine if the
alert looks to be real and file a bug with the appropriate label if so.
Note that if no label more specific than Internals>Network is appropriate,
the responsibility remains with the triager to continue investigating the
bug, as above.
Note that if no label more specific than Internals&gt;Network is
appropriate, the responsibility remains with the triager to continue
investigating the bug, as above.
* The triager is responsible for looking at any notification previous
triagers did not, so when an issue is investigated, the person who did
so should respond to chrome-network-debugging@google.com with a short
email, describing their conclusions. Future triagers can then use the
fact an alert was responded to as an indicator of which of them need
to be followed up on. Alerts fired before the beginning of the
previous triager's rotation may be ignored.
previous triager's rotation may be ignored.
* Investigate [Unconfirmed / Untriaged Internals>Network issues that don't belong to a more specific network component](https://bugs.chromium.org/p/chromium/issues/list?can=2&q=component%3DInternals%3ENetwork+status%3AUnconfirmed,Untriaged+-label:Needs-Feedback&sort=-modified),
prioritizing the most recent issues, ones with the most responsive reporters,
......@@ -82,8 +82,8 @@ uniform, predictable two day commitment for all triagers.
due to the way the bug report wizard works, a lot of bugs incorrectly end
up with the network component.
* The issue is assigned to an appropriate owner, and make sure to mark it
as "assigned" so the next triager doesn't run into it.
* The issue is assigned to an appropriate owner. Make sure to mark it as
"assigned" so the next triager doesn't run into it.
* If there is no more specific component for a bug, it should be
investigated by the triager until we have a good understanding of the
......@@ -118,6 +118,10 @@ uniform, predictable two day commitment for all triagers.
* Make sure to check for new crashes on all platforms, not just Windows.
* [go/chromenetcrash](https://goto.google.com/chromenetcrash) has a list
of net crashes by version, though makes it more difficult to tell if a
crash makes up a significant portion of all Chrome crashes.
### Best Effort (As you have time):
* Investigate old bugs, and bugs associated with Internals>Network
......@@ -125,8 +129,8 @@ uniform, predictable two day commitment for all triagers.
* Investigate unowned and owned but forgotten net/ crashers that are still
occurring (As indicated by
[go/chromecrash](https://goto.google.com/chromecrash)), prioritizing frequent
and long standing crashers.
[go/chromenetcrash](https://goto.google.com/chromenetcrash)), prioritizing
frequent and long standing crashers.
* Close obsolete bugs.
......@@ -137,4 +141,4 @@ See [bug-triage-labels.md](bug-triage-labels.md) for labeling tips for network
and non-network bugs.
See [crash-course-in-net-internals.md](crash-course-in-net-internals.md) for
some help on getting started with about:net-internals debugging.
some help on getting started with chrome://net-internals debugging.
net/docs/crash-course-in-net-internals.md
View file @ ae32850c
# A Crash Course in Debugging with about:net-internals
# A Crash Course in Debugging with chrome://net-internals
This document is intended to help get people started debugging network errors
with about:net-internals, with some commonly useful tips and tricks. This
with chrome://net-internals, with some commonly useful tips and tricks. This
document is aimed more at how to get started using some of its features to
investigate bug reports, rather than as a feature overview.
......@@ -10,9 +10,9 @@ It would probably be useful to read
# What Data Net-Internals Contains
about:net-internals provides a view of browser activity from net/'s perspective.
For this reason, it lacks knowledge of tabs, navigation, frames, resource types,
etc.
chrome://net-internals provides a view of browser activity from net/'s
perspective. For this reason, it lacks knowledge of tabs, navigation, frames,
resource types, etc.
The leftmost column presents a list of views. Most debugging is done with the
Events view, which will be all this document covers.
......@@ -23,13 +23,13 @@ single, global, ChromeNetLog object. This includes both incognito and
non-incognito profiles, among other things. The Events view only shows events
for the period that net-internals was open and running, and is incrementally
updated as events occur. The code attempts to add a top level event for
URLRequests that were active when the about:net-internals tab was opened, to
URLRequests that were active when the chrome://net-internals tab was opened, to
help debug hung requests, but that's best-effort only, and only includes
requests for the current profile and the system URLRequestContext.
The other views are all snapshots of the current state of the main
URLRequestContext's components, and are updated on a 5 second timer. These will
show objects that were created before about:net-internals was opened.
show objects that were created before chrome://net-internals was opened.
# Events vs Sources
......@@ -165,7 +165,7 @@ should generally ignore those, and look for a more interesting one.
This is often useful in finding hung or slow requests.
For a list of other filter commands, you can mouse over the question mark on
about:net-internals.
chrome://net-internals.
Once you locate the problematic request, the next is to figure out where the
problem is -- it's often one of the last events, though it could also be related
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment