aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/trace/trace.go
AgeCommit message (Collapse)Author
2023-02-10cmd/trace: fix error message for bad goroutine state transitionNick Ripley
The error message when an invalid goroutine state transition is found in a trace should show the current state, not the next state, when comparing against the expected current state. This CL also picks up a gofmt change to the file. Change-Id: Ic0ce6c9ce79d8a784b73b115b5db76c311b8593d Reviewed-on: https://go-review.googlesource.com/c/go/+/467416 Auto-Submit: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: David Chase <drchase@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-11-07cmd/trace: only include required frames in splitsMichael Pratt
Though we split traces into 100MB chunks, currently each chunk always includes the entire stack frame map, including frames for all events in the trace file, even if they aren't needed by events in this chunk. This means that if the stack frame JSON alone is >100MB then there is no space at all for events. In that case, we'll generate splits each containing 1 event, which is effectively useless. Handle this more efficiently by only including stack frames referenced by events in the chunk. Each marginal events only adds at most a few dozen stack frames, so it should now longer be possible to only include a tiny number of events. Fixes #56444. Change-Id: I58aa8f271c32678028b72d82df16e6ea762ebb39 Reviewed-on: https://go-review.googlesource.com/c/go/+/445895 Run-TryBot: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-10-03cmd/trace: replace loop with append(slice, slice2...)cuiweixie
Change-Id: I4686f36a8f718fea1a08d816bc14e24e3528bb07 Reviewed-on: https://go-review.googlesource.com/c/go/+/436706 Auto-Submit: Ian Lance Taylor <iant@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com> Reviewed-by: hopehook <hopehook@golangcn.org> Run-TryBot: xie cui <523516579@qq.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Ian Lance Taylor <iant@google.com>
2022-07-11internal/trace: don't report regions on system goroutinesMichael Pratt
If a goroutine is started within a user region, internal/trace assigns the child goroutine a nameless region for its entire lifetime which is assosciated the same task as the parent's region. This is not strictly necessary: a child goroutine is not necessarily related to the task unless it performs some task operation (in which case it will be associated with the task through the standard means). However, it can be quite handy to see child goroutines within a region, which may be child worker goroutines that you simply didn't perform task operations on. If the first GC occurs during a region, the GC worker goroutines will also inherit a child region. We know for sure that these aren't related to the task, so filter them out from the region list. Note that we can't exclude system goroutines from setting activeRegions in EvGoCreate handling, because we don't know the goroutine start function name until the first EvGoStart. Fixes #53784. Change-Id: Ic83d84e23858a8400a76d1ae2f1418ef49951178 Reviewed-on: https://go-review.googlesource.com/c/go/+/416858 Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2022-05-03runtime: add CPU samples to execution traceRhys Hiltner
When the CPU profiler and execution tracer are both active, report the CPU profile samples in the execution trace data stream. Include only samples that arrive on the threads known to the runtime, but include them even when running g0 (such as near the scheduler) or if there's no P (such as near syscalls). Render them in "go tool trace" as instantaneous events. For #16895 Change-Id: I0aa501a7b450c971e510961c0290838729033f7f Reviewed-on: https://go-review.googlesource.com/c/go/+/400795 Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Rhys Hiltner <rhys@justin.tv> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-04-21cmd/trace: embed static contentMichael Pratt
cmd/trace is currently somewhat painful to use in odd environments since it depends on the presence of $GOROOT/misc/trace to serve the static trace viewer content. Use //go:embed to embed this content directly into cmd/trace for easier use. Change-Id: I83b7d97dbecc9773f3b5a6b3bc4a6597473bc01a Reviewed-on: https://go-review.googlesource.com/c/go/+/378194 Run-TryBot: Michael Pratt <mpratt@google.com> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-12-13all: gofmt -w -r 'interface{} -> any' srcRuss Cox
And then revert the bootstrap cmd directories and certain testdata. And adjust tests as needed. Not reverting the changes in std that are bootstrapped, because some of those changes would appear in API docs, and we want to use any consistently. Instead, rewrite 'any' to 'interface{}' in cmd/dist for those directories when preparing the bootstrap copy. A few files changed as a result of running gofmt -w not because of interface{} -> any but because they hadn't been updated for the new //go:build lines. Fixes #49884. Change-Id: Ie8045cba995f65bd79c694ec77a1b3d1fe01bb09 Reviewed-on: https://go-review.googlesource.com/c/go/+/368254 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-04-14runtime: move next_gc and last_next_gc into gcControllerStateMichael Anthony Knyszek
This change moves next_gc and last_next_gc into gcControllerState under the names heapGoal and lastHeapGoal respectively. These are fundamentally GC pacer related values, and so it makes sense for them to live here. Partially generated by rf ' ex . { memstats.next_gc -> gcController.heapGoal memstats.last_next_gc -> gcController.lastHeapGoal } ' except for updates to comments and gcControllerState methods, where they're accessed through the receiver, and trace-related renames of NextGC -> HeapGoal, while we're here. For #44167. Change-Id: I1e871ad78a57b01be8d9f71bd662530c84853bed Reviewed-on: https://go-review.googlesource.com/c/go/+/306603 Trust: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
2020-08-12cmd/trace: move viewer data structs into cmd/internal/traceviewerMichael Matloob
The ViewerEvent, ViewerData and ViewerFrame structs are moved into cmd/internal/traceviewer, and renamed Event, Data, and Frame. The structs are the same, except for the following: A definition for the JSON "bp" field that's defined in the trace format, but missing in the structs has been added. Also, the Tid and Pid fields on Event have been renamed TID and PID to better match Go style. Finally, the footer field on ViewerData, which hasn't been used for a while, has been removed. This CL is in preparation for the usage of these structs by cmd/go's tracing functionality. Updates #38714 Change-Id: I345f23617b96d4629b876ae717f89d56a67e05a3 Reviewed-on: https://go-review.googlesource.com/c/go/+/239098 Run-TryBot: Michael Matloob <matloob@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Jay Conrod <jayconrod@google.com>
2020-02-20cmd/trace: update to use WebComponents V0 polyfillHana (Hyang-Ah) Kim
Old trace viewer stopped working with Chrome M80+ because the old trace viewer heavily depended on WebComponents V0 which are deprecated. Trace viewer recently migrated to use WebComponents V0 polyfill (crbug.com/1036492). This CL brings in the newly updated trace_viewer_full.html (sync'd @ 9508452e) and updates the javascript snippet included in the /trace endpoint to use the polyfill. This brings in webcomponents.min.js copied from https://chromium.googlesource.com/catapult/+/9508452e18f130c98499cb4c4f1e1efaedee8962/third_party/polymer/components/webcomponentsjs/webcomponents.min.js That is necessary because the /trace endpoint needs to import the vulcanized trace_viewer_full.html. It's possible that some features are not working correctly with this polyfill. In that case, report the issue to crbug.com/1036492. There will be a warning message in the UI (yellow banner above the timeline) which can be hidden by clicking the 'hide' button. This allows to render the trace in browsers other than chrome in theory, but I observed some buttons and functions still don't work outside chrome. Fixes #34374. Change-Id: Ib575f756f5e6b22ad904ede6e4d224a995ebe259 Reviewed-on: https://go-review.googlesource.com/c/go/+/219997 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2018-11-22cmd/trace: revert internal/traceparserHana Kim
The performance improvement is not as big as we hoped. Until the API is feature complete, we postpone the release and avoid added complexity. This change was prepared by reverting all the changes affected src/cmd/trace and src/internal/traceparser packages after golang.org/cl/137635, and then bringing back MMU computation APIs (originally in src/internal/traceparser) to the src/internal/trace package. Revert "cmd/trace: use new traceparser to parse the raw trace files" This reverts https://golang.org/cl/145457 (commit 08816cb8d7ed16b9c804587ff02c1ad1c3af6cd5). Revert "internal/traceparser: provide parser that uses less space and parses segments of runtime trace files" This reverts https://golang.org/cl/137635 (commit daaf361f74c3665bcb364356c5a9dd9f536c78c3). Change-Id: Ic2a068a7dbaf4053cd9674ca7bde9c58e74385b4 Reviewed-on: https://go-review.googlesource.com/c/150517 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com>
2018-11-05cmd/trace: list and link to worst mutator utilization windowsAustin Clements
This adds the ability to click a point on the MMU graph to show a list of the worst 10 mutator utilization windows of the selected size. This list in turn links to the trace viewer to drill down on specifically what happened in each specific window. Change-Id: Ic1b72d8b37fbf2212211c513cf36b34788b30133 Reviewed-on: https://go-review.googlesource.com/c/60795 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-10-30cmd/trace: use new traceparser to parse the raw trace filesPeter Weinberger
Change-Id: I8b224ae48a2f8acd5a64c9ff283e97821479a9a8 Reviewed-on: https://go-review.googlesource.com/c/145457 Run-TryBot: Peter Weinberger <pjw@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2018-09-26all: use strings.ReplaceAll and bytes.ReplaceAll where applicableBrad Fitzpatrick
I omitted vendor directories and anything necessary for bootstrapping. (Tested by bootstrapping with Go 1.4) Updates #27864 Change-Id: I7d9b68d0372d3a34dee22966cca323513ece7e8a Reviewed-on: https://go-review.googlesource.com/137856 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2018-09-17cmd/trace: don't drop sweep slice detailsHana Kim
For sweep events, we used to modify the ViewerEvent returned from ctx.emitSlice later in order to embed more details about the sweep operation. The trick no longer works after the change https://golang.org/cl/92375 and caused a regression. ctx.emit method encodes the ViewerEvent, so any modification to the ViewerEvent object after ctx.emit returns will not be reflected. Refactor ctx.emitSlice, so ctx.makeSlice can be used when producing slices for SWEEP. ctx.emit* methods are meant to truely emit ViewerEvents. Fixes #27711 Change-Id: I0b733ebbbfd4facd8714db0535809ec3cab0833d Reviewed-on: https://go-review.googlesource.com/135775 Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-08-30all: fix typosAlex Kohler
Change-Id: Icded6c786b7b185d5aff055f34e0cfe9e521826a Reviewed-on: https://go-review.googlesource.com/132176 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2018-05-21cmd/trace: fix a few bugs found by staticcheckDaniel Martí
First, the regions sort was buggy, as its last comparison was ineffective. Second, the insyscall and insyscallRuntime fields were unsigned, so the check for them being negative was pointless. Make them signed instead, to also prevent the possibility of underflows when decreasing numbers that might realistically be 0. Third, the color constants were all untyped strings except the first one. Be consistent with their typing. Change-Id: I4eb8d08028ed92589493c2a4b9cc5a88d83f769b Reviewed-on: https://go-review.googlesource.com/113895 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-05-08cmd/trace: handle invalid goid para in /traceHana (Hyang-Ah) Kim
Change-Id: I1cb7c8b70a5ae16386f6abb577c23d821f7ff7f0 Reviewed-on: https://go-review.googlesource.com/112197 Reviewed-by: Peter Weinberger <pjw@google.com> Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com>
2018-05-07runtime: replace system goroutine whitelist with symbol testAustin Clements
Currently isSystemGoroutine has a hard-coded list of known entry points into system goroutines. This list is annoying to maintain. For example, it's missing the ensureSigM goroutine. Replace it with a check that simply looks for any goroutine with runtime function as its entry point, with a few exceptions. This also matches the definition recently added to the trace viewer (CL 81315). Change-Id: Iaed723d4a6e8c2ffb7c0c48fbac1688b00b30f01 Reviewed-on: https://go-review.googlesource.com/81655 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2018-04-29cmd/trace: use different colors for tasksHana Kim
and assign the same colors for spans belong to the tasks (sadly, the trace viewer will change the saturation/ligthness for asynchronous slices so exact color mapping is impossible. But I hope they are not too far from each other) Change-Id: Idaaf0828a1e0dac8012d336dcefa1c6572ddca2e Reviewed-on: https://go-review.googlesource.com/109338 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
2018-04-26cmd/trace: have tasks in a separate section (process group)Hana Kim
Also change tasks to be represented as "slices" instead of asynchronous events which are more efficiently represented in trace viewer data model. This change allows to utilize the flow events (arrows) to represent task hierarchies. Introduced RegionArgs and TaskArgs where the task id infomation and goroutine id informations are stored for information-purpose. Change-Id: I11bec7dd716fdfc5f94ea39661b2e51344367a6f Reviewed-on: https://go-review.googlesource.com/109337 Reviewed-by: Heschi Kreinick <heschi@google.com>
2018-04-24cmd/trace: distinguish task endTimestamp and lastTimestampHana Kim
A task may have other user annotation events after the task ends. So far, task.lastTimestamp returned the task end event if the event available. This change introduces task.endTimestamp for that and makes task.lastTimestamp returns the "last" seen event's timestamp if the task is ended. If the task is not ended, both returns the last timestamp of the entire trace assuming the task is still active. This fixes the task-oriented trace view mode not to drop user annotation instances when they appear outside a task's lifespan. Adds a test. Change-Id: Iba1062914f224edd521b9ee55c6cd5e180e55359 Reviewed-on: https://go-review.googlesource.com/109175 Reviewed-by: Heschi Kreinick <heschi@google.com>
2018-04-24runtime/trace: rename "Span" with "Region"Hana Kim
"Span" is a commonly used term in many distributed tracing systems (Dapper, OpenCensus, OpenTracing, ...). They use it to refer to a period of time, not necessarily tied into execution of underlying processor, thread, or goroutine, unlike the "Span" of runtime/trace package. Since distributed tracing and go runtime execution tracing are already similar enough to cause confusion, this CL attempts to avoid using the same word if possible. "Region" is being used in a certain tracing system to refer to a code region which is pretty close to what runtime/trace.Span currently refers to. So, replace that. https://software.intel.com/en-us/itc-user-and-reference-guide-defining-and-recording-functions-or-regions This CL also tweaks APIs a bit based on jbd and heschi's comments: NewContext -> NewTask and it now returns a Task object that exports End method. StartSpan -> StartRegion and it now returns a Region object that exports End method. Also, changed WithSpan to WithRegion and it now takes func() with no context. Another thought is to get rid of WithRegion. It is a nice concept but in practice, it seems problematic (a lot of code churn, and polluting stack trace). Already, the tracing concept is very low level, and we hope this API to be used with great care. Recommended usage will be defer trace.StartRegion(ctx, "someRegion").End() Left old APIs untouched in this CL. Once the usage of them are cleaned up, they will be removed in a separate CL. Change-Id: I73880635e437f3aad51314331a035dd1459b9f3a Reviewed-on: https://go-review.googlesource.com/108296 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: JBD <jbd@google.com>
2018-04-13cmd/trace: change span id computation for trace view useHana Kim
golang.org/cl/102697 attempted to fix the span presentation by utilizing the position of the span in the span slices of a task. But it is not complete either. First, id=0 is omitted in json encoding and the trace viewer silently drops entries with the missing id field, so we must avoid zero-value id. Second, it is possible that a goroutine handles multiple tasks. Then, id collisions will happen. This takes a simpler approach - have a counter that increments for every emitSpan call, and use the value as the id value. Change-Id: Idaa9505634acf6d327c6f00af32d8260955b85e1 Reviewed-on: https://go-review.googlesource.com/106755 Reviewed-by: Heschi Kreinick <heschi@google.com> Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-04-04cmd/trace: avoid emitting traceview slice with 0 durationHana Kim
The trace viewer interprets the slice as a non-terminating time interval which is quite opposit to what trace records indicate (i.e., almostly immediately terminating time interval). As observed in the issue #24663 this can result in quite misleading visualization of the trace. Work around the trace viewer's issue by setting a small value (0.0001usec) as the duration if the time interval is not positive. Change-Id: I1c2aac135c194d0717f5c01a98ca60ffb14ef45c Reviewed-on: https://go-review.googlesource.com/104716 Reviewed-by: Heschi Kreinick <heschi@google.com>
2018-04-04cmd/trace: implement /trace?focustask=<taskid> modeHana Kim
This mode is similar to the default traceview mode where the execution trace is presented in P-oriented way. Each row represents a P, and each slice represents the time interval of a goroutine's execution on the P. The difference is that, in this mode, only the execution of goroutines involved in the specified task is highlighted, and other goroutine execution or events are greyed out. So, users can focus on how a task is executed while considering other affecting conditions such as other goroutines, network events, or process scheduling. Example: https://user-images.githubusercontent.com/4999471/38116793-a6f995f0-337f-11e8-8de9-88eec2f2c497.png Here, for a while the program remained idle after the first burst of activity related to the task because all other goroutines were also being blocked or waiting for events, or no incoming network traffic (indicated by the lack of any network activity). This is a bit hard to discover when the usual task-oriented view (/trace?taskid=<taskid>) mode. Also, it simplifies the traceview generation mode logic. /trace ---> 0 /trace?goid ---> modeGoroutineOriented /trace?taskid ---> modeGoroutineOriented|modeTaskOriented /trace?focustask ---> modeTaskOriented Change-Id: Idcc0ae31b708ddfd19766f4e26ee7efdafecd3a5 Reviewed-on: https://go-review.googlesource.com/103555 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> Reviewed-by: Heschi Kreinick <heschi@google.com>
2018-03-27cmd/trace: assign a unique span id for slice representationHana Kim
Spans are represented using Async Event types of chrome trace viewer. According to the doc, the 'id' should be unique within category, scope. https://docs.google.com/document/d/1CvAClvFfyA5R-PhYUmn5OOQtYMH4h6I0nSsKchNAySU/preview#heading=h.jh64i9l3vwa1 Use the index in the task's span slice as the slice id, so it can be unique within the task. The scope is the task id which is unique. This fixes a visualization bug that caused incorrect or missing presentation of nested spans. Change-Id: If1537ee00247f71fa967abfe45569a9e7dbcdce7 Reviewed-on: https://go-review.googlesource.com/102697 Reviewed-by: Heschi Kreinick <heschi@google.com>
2018-03-26cmd/trace: add /userspans, /userspan pagesHana Kim
Change-Id: Ifbefb659a8df3b079d69679871af444b179deaeb Reviewed-on: https://go-review.googlesource.com/102599 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
2018-03-26internal/trace: compute span stats as computing goroutine statsHana Kim
Move part of UserSpan event processing from cmd/trace.analyzeAnnotations to internal/trace.GoroutineStats that returns analyzed per-goroutine execution information. Now the execution information includes list of spans and their execution information. cmd/trace.analyzeAnnotations utilizes the span execution information from internal/trace.GoroutineStats and connects them with task information. Change-Id: Ib7f79a3ba652a4ae55cd81ea17565bcc7e241c5c Reviewed-on: https://go-review.googlesource.com/101917 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com> Reviewed-by: Peter Weinberger <pjw@google.com>
2018-03-09cmd/trace: set cname for span slicesHana Kim
Define a set of color names available in trace viewer https://user-images.githubusercontent.com/4999471/37063995-5d0bad48-2169-11e8-92be-9cb363e21c38.png Change-Id: I312fcbc5430d7512b4c39ddc79a769259bad8c22 Reviewed-on: https://go-review.googlesource.com/99055 Reviewed-by: Heschi Kreinick <heschi@google.com>
2018-03-09cmd/trace: remove unrelated arrows in task-oriented traceviewHana Kim
Also grey out instants that represent events occurred outside the task's span. Furthermore, if the unrelated instants represent user annotation events but not for the task of the interest, skip rendering completely. This helps users to focus on the task-related events better. UI screen shot: https://gist.github.com/hyangah/1df5d2c8f429fd933c481e9636b89b55#file-golang-org_cl_99035 Change-Id: I2b5aef41584c827f8c1e915d0d8e5c95fe2b4b65 Reviewed-on: https://go-review.googlesource.com/99035 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> Run-TryBot: Heschi Kreinick <heschi@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
2018-03-07cmd/trace: force GC occassionallyHana Kim
to return memory to the OS after completing potentially large operations. Update #21870 Sys went down to 3.7G $ DEBUG_MEMORY_USAGE=1 go tool trace trace.out 2018/03/07 09:35:52 Parsing trace... after parsing trace Alloc: 3385754360 Bytes Sys: 3662047864 Bytes HeapReleased: 0 Bytes HeapSys: 3488907264 Bytes HeapInUse: 3426549760 Bytes HeapAlloc: 3385754360 Bytes Enter to continue... 2018/03/07 09:36:09 Splitting trace... after spliting trace Alloc: 3238309424 Bytes Sys: 3684410168 Bytes HeapReleased: 0 Bytes HeapSys: 3488874496 Bytes HeapInUse: 3266461696 Bytes HeapAlloc: 3238309424 Bytes Enter to continue... 2018/03/07 09:36:39 Opening browser. Trace viewer is listening on http://100.101.224.241:12345 after httpJsonTrace Alloc: 3000633872 Bytes Sys: 3693978424 Bytes HeapReleased: 0 Bytes HeapSys: 3488743424 Bytes HeapInUse: 3030966272 Bytes HeapAlloc: 3000633872 Bytes Enter to continue... Change-Id: I56f64cae66c809cbfbad03fba7bd0d35494c1d04 Reviewed-on: https://go-review.googlesource.com/92376 Reviewed-by: Peter Weinberger <pjw@google.com>
2018-03-07cmd/trace: generate jsontrace data in a streaming fashionHana Kim
Update #21870 The Sys went down to 4.25G from 6.2G. $ DEBUG_MEMORY_USAGE=1 go tool trace trace.out 2018/03/07 08:49:01 Parsing trace... after parsing trace Alloc: 3385757184 Bytes Sys: 3661195896 Bytes HeapReleased: 0 Bytes HeapSys: 3488841728 Bytes HeapInUse: 3426516992 Bytes HeapAlloc: 3385757184 Bytes Enter to continue... 2018/03/07 08:49:18 Splitting trace... after spliting trace Alloc: 2352071904 Bytes Sys: 4243825464 Bytes HeapReleased: 0 Bytes HeapSys: 4025712640 Bytes HeapInUse: 2377703424 Bytes HeapAlloc: 2352071904 Bytes Enter to continue... after httpJsonTrace Alloc: 3228697832 Bytes Sys: 4250379064 Bytes HeapReleased: 0 Bytes HeapSys: 4025647104 Bytes HeapInUse: 3260014592 Bytes HeapAlloc: 3228697832 Bytes Change-Id: I546f26bdbc68b1e58f1af1235a0e299dc0ff115e Reviewed-on: https://go-review.googlesource.com/92375 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> Reviewed-by: Peter Weinberger <pjw@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2018-02-21cmd/trace: add memory usage reportingHana Kim
Enabled when the tool runs with DEBUG_MEMORY_USAGE=1 env var. After reporting the usage, it waits until user enters input (helpful when checking top or other memory monitor) Also adds net/http/pprof to export debug endpoints. From the trace included in #21870 $ DEBUG_MEMORY_USAGE=1 go tool trace trace.out 2018/02/21 16:04:49 Parsing trace... after parsing trace Alloc: 3385747848 Bytes Sys: 3661654648 Bytes HeapReleased: 0 Bytes HeapSys: 3488907264 Bytes HeapInUse: 3426377728 Bytes HeapAlloc: 3385747848 Bytes Enter to continue... 2018/02/21 16:05:09 Serializing trace... after generating trace Alloc: 4908929616 Bytes Sys: 5319063640 Bytes HeapReleased: 0 Bytes HeapSys: 5032411136 Bytes HeapInUse: 4982865920 Bytes HeapAlloc: 4908929616 Bytes Enter to continue... 2018/02/21 16:05:18 Splitting trace... after spliting trace Alloc: 4909026200 Bytes Sys: 5319063640 Bytes HeapReleased: 0 Bytes HeapSys: 5032411136 Bytes HeapInUse: 4983046144 Bytes HeapAlloc: 4909026200 Bytes Enter to continue... 2018/02/21 16:05:39 Opening browser. Trace viewer is listening on http://127.0.0.1:33661 after httpJsonTrace Alloc: 5288336048 Bytes Sys: 7790245896 Bytes HeapReleased: 0 Bytes HeapSys: 7381123072 Bytes HeapInUse: 5324120064 Bytes HeapAlloc: 5288336048 Bytes Enter to continue... Change-Id: I88bb3cb1af3cb62e4643a8cbafd5823672b2e464 Reviewed-on: https://go-review.googlesource.com/92355 Reviewed-by: Peter Weinberger <pjw@google.com>
2018-02-21cmd/trace: include P info in goroutine slicesHana Kim
The task-oriented trace view presents the execution trace organized based on goroutines. Often, which P a goroutine was running on is useful, so this CL includes the P ids in the goroutine execution slices. R=go1.11 Change-Id: I96539bf8215e5c1cd8cc997a90204f57347c48c8 Reviewed-on: https://go-review.googlesource.com/90221 Reviewed-by: Heschi Kreinick <heschi@google.com>
2018-02-21cmd/trace: add user log event in the task-oriented trace viewHana Kim
Also append stack traces to task create/end slices. R=go1.11 Change-Id: I2adb342e92b36d30bee2860393618eb4064450cf Reviewed-on: https://go-review.googlesource.com/90220 Reviewed-by: Heschi Kreinick <heschi@google.com>
2018-02-21cmd/trace: present the GC time in the usertask viewHana Kim
The GC time for a task is defined by the sum of GC duration overlapping with the task's duration. Also, grey out non-overlapping slices in the task-oriented trace view. R=go1.11 Change-Id: I42def0eb520f5d9bd07edd265e558706f6fab552 Reviewed-on: https://go-review.googlesource.com/90219 Reviewed-by: Heschi Kreinick <heschi@google.com>
2018-02-20cmd/trace: task-oriented view includes child tasksHana Kim
R=go1.11 Change-Id: Ibb09e309c745eba811a0b53000c063bc10a055e1 Reviewed-on: https://go-review.googlesource.com/90218 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Peter Weinberger <pjw@google.com>
2018-02-20cmd/trace: extend trace view (/trace) for task-oriented viewHana Kim
R=go1.11 Change-Id: I2d2db148fed96d0fcb228bee414b050fe4e46e2c Reviewed-on: https://go-review.googlesource.com/90217 Reviewed-by: Heschi Kreinick <heschi@google.com>
2018-02-20cmd/trace: add analyzeAnnotation and /usertasks view.Hana Kim
R=go1.11 Change-Id: I5078ab714c8ac2c652e6ec496e01b063235a014a Reviewed-on: https://go-review.googlesource.com/90216 Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Heschi Kreinick <heschi@google.com>
2018-02-20cmd/trace: encode selection in trace URLAustin Clements
This adds the ability to add a #x:y anchor to the trace view URL that causes the viewer to initially select from x ms to y ms. Change-Id: I4a980d8128ecc85dbe41f224e8ae336707a4eaab Reviewed-on: https://go-review.googlesource.com/60794 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2017-12-20cmd/trace: init goroutine info entries with GoCreate eventHana Kim
golang.org/cl/81315 attempted to distinguish system goroutines by examining the function name in the goroutine stack. It assumes that the information would be available when GoSysBlock or GoInSyscall events are processed, but it turned out the stack information is set too late (when the goroutine gets a chance to run). This change initializes the goroutine information entry when processing GoCreate event which should be one of the very first events for the every goroutine in trace. Fixes #22574 Change-Id: I1ed37087ce2e78ed27c9b419b7d942eb4140cc69 Reviewed-on: https://go-review.googlesource.com/83595 Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-12-01cmd/trace: exclude threads in syscall on behalf of runtimeHana Kim
The number of threads in syscall presented by execution tracer's trace view includes not only the threads calling system calls on behalf of user created goroutines, but also those running on behalf of system goroutines. When the number of such system goroutines was small, the graph was useful when examining where a program was saturating the CPU. But as more and more system goroutines are invloved the graph became less useful for the purpose - for example, after golang.org/cl/34784, the timer goroutines dominate in the graph with large P because the runtime creates per-P timer goroutines. This change excludes the threads in syscall on behalf of runtime (system goroutines) from the visualization. Alternatively, I could visualize the count of such threads in a separate counter but in the same graph. Given that many other debug endpoints (e.g. /debug/pprof/goroutine) hide the system goroutines, including them in the same graph can confuse users. Update #22574 Change-Id: If758cd6b9ed0596fde9a471e846b93246580b9d5 Reviewed-on: https://go-review.googlesource.com/81315 Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Hyang-Ah Hana Kim <hyangah@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-11-16cmd/internal/obj, cmd/trace: restore bounds checks dropped in CL 56950Russ Cox
CL 56950 correctly identified code with checks that were impossible. But instead of correcting the checks it deleted them. This CL corrects the code to check what was meant. Change-Id: Ic89222184ee4fa5cacccae12d750601a9438ac8d Reviewed-on: https://go-review.googlesource.com/78113 Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2017-10-20cmd/trace: fix a javascript bug in handling import errorHana Kim
When traceviewer encounters a failure of json trace import due to data error, onImportFail tried to access an error variable which was not yet defined. Change-Id: I431be03f179aafacaf1fd3c62a6337e8b5bd18fb Reviewed-on: https://go-review.googlesource.com/71970 Reviewed-by: Austin Clements <austin@google.com>
2017-08-29runtime,cmd/trace: trace GC STW eventsAustin Clements
Right now we only kind of sort of trace GC STW events. We emit events around mark termination, but those start well after stopping the world and end before starting it again, and we don't emit any events for sweep termination. Fix this by generalizing EvGCScanStart/EvGCScanDone. These were already re-purposed to indicate mark termination (despite the names). This commit renames them to EvGCSTWStart/EvGCSTWDone, adds an argument to indicate the STW reason, and shuffles the runtime to generate them right before stopping the world and right after starting the world, respectively. These events will make it possible to generate precise minimum mutator utilization (MMU) graphs and could be useful in detecting non-preemptible goroutines (e.g., #20792). Change-Id: If95783f370781d8ef66addd94886028103a7c26f Reviewed-on: https://go-review.googlesource.com/55411 Reviewed-by: Rick Hudson <rlh@golang.org>
2017-08-25misc/trace: update trace-viewerHana Kim
Generated with github.com/catapult/tracing/bin/vulcanize_trace_viewer catapult @ ab4d571fa Renamed trace_viewer_lean.html to trace_viewer_full.html to make it clear we are using the full version of trace viewer (waiting for https://github.com/catapult-project/catapult/issues/2247 to be fixed). Update #15302 Change-Id: Ice808bb27ab79a1dec9fc863e0c5a761027ebfbe Reviewed-on: https://go-review.googlesource.com/58750 Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
2017-08-18cmd/*: remove negative uint checksDaniel Martí
All of these are uints of different sizes, so checking >= 0 or < 0 are effectively no-ops. Found with staticcheck. Change-Id: I16ac900eb7007bc8f9018b302136d42e483a4180 Reviewed-on: https://go-review.googlesource.com/56950 Reviewed-by: Matt Layher <mdlayher@gmail.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Matt Layher <mdlayher@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2017-08-11cmd/trace: don't shift trace slices to 0Austin Clements
Currently all trace slices get shifted to start at time 0. This makes it very difficult to find specific points in time unless they fall in the first slice. For example, right now when you click "View trace (6.005646218s-8.155419698s)" on the trace tool's main page, the trace view puts the first event in that slice at time 0. If you're looking for something that happened at time 7s, you have to look at time 0.9943537s in the trace view. And if you want to subtract times taken from different slices, you have to figure out what those time really correspond to. Fix this by telling the trace viewer not to shift the times when it imports the trace. In the above example, this makes the view of that second trace slice start at time 6.005646218s, so you don't have to do any gymnastics to find or calculate times in later slices. Change-Id: I04e0afda60f5573fdd8ad96238c24013297ef263 Reviewed-on: https://go-review.googlesource.com/54633 Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
2017-08-11cmd/trace: update HTML; expand viewer to whole windowAustin Clements
This updates the HTML served for the trace viewer to follow the latest revision of the example from the upstream tracing project. The main thing this adds is CSS for the trace viewer (which was actually in the example at the originally referenced revision, so I'm not sure why it got dropped). In particular, this expands the trace viewer to use the entire browser client area, which fixes several problems with the current page: 1. The details pane gets cut off at a strange place and can get a scroll bar even if there's plenty of room below it on the page. This fixes the bottom of the details pane to the bottom of the window. 2. If the track view is very tall (lots of procs), there's no way to view the top tracks and the details pane at the same time. This fixes this problem by limiting the height of the track view to something less than the height of the window so it gets a scroll bar of its own if necessary. 3. Dragging the divider between the track pane and the details pane actually moves the bottom of the details pane without moving the divider. Fixing the height of the trace viewer fixes this problem. Change-Id: Ia811e72a7413417ca21c45e932c9db2724974633 Reviewed-on: https://go-review.googlesource.com/54632 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Hyang-Ah Hana Kim <hyangah@gmail.com>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 07:47:53 +0000