aboutsummaryrefslogtreecommitdiff
path: root/src/runtime/traceback.go
AgeCommit message (Collapse)Author
2025-06-09runtime: clarify stack traces for bubbled goroutinesDamien Neil
Use the synctest bubble ID to identify bubbles in traces, rather than the goroutine ID of the bubble's root goroutine. Some waitReasons include a "(synctest)" suffix to distinguish a durably blocking state from a non-durable one. For example, "chan send" vs. "chan send (synctest)". Change this suffix to "(durable)". Always print a "(durable)" sufix for the state of durably blocked bubbled goroutines. For example, print "sleep (durable)". Drop the "[not] durably blocked" text from goroutine states, since this is now entirely redundant with the waitReason. Old: goroutine 8 [chan receive (synctest), synctest bubble 7, durably blocked]: goroutine 9 [select (no cases), synctest bubble 7, durably blocked]: New: goroutine 8 [chan receive (durable), synctest bubble 1]: goroutine 9 [select (no cases) (durable), synctest bubble 1]: Change-Id: I89112efb25150a98a2954f54d1910ccec52a5824 Reviewed-on: https://go-review.googlesource.com/c/go/+/679376 Auto-Submit: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-05-20runtime: print blocking status of bubbled goroutines in stacksDamien Neil
For goroutines in a synctest bubble, include whether the goroutine is "durably blocked" or not in the goroutine status. Synctest categorizes goroutines in certain states as "durably" blocked, where the goroutine is not merely idle but can only be awoken by another goroutine in its bubble. To make it easier for users to understand why a bubble is or is not idle, print the state of each bubbled goroutine. For example: goroutine 36 [chan receive, synctest bubble 34, not durably blocked]: goroutine 37 [chan receive (synctest), synctest bubble 34, durably blocked]: Goroutine 36 is receiving from a channel created outside its bubble. Goroutine 36 is receiving from a channel created inside its bubble. For #67434 Change-Id: I006b656a9ce7eeb75b2be21e748440a5dd57ceb0 Reviewed-on: https://go-review.googlesource.com/c/go/+/670976 Auto-Submit: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2025-05-08runtime: schedule cleanups across multiple goroutinesMichael Anthony Knyszek
This change splits the finalizer and cleanup queues and implements a new lock-free blocking queue for cleanups. The basic design is as follows: The cleanup queue is organized in fixed-sized blocks. Individual cleanup functions are queued, but only whole blocks are dequeued. Enqueuing cleanups places them in P-local cleanup blocks. These are flushed to the full list as they get full. Cleanups can only be enqueued by an active sweeper. Dequeuing cleanups always dequeues entire blocks from the full list. Cleanup blocks can be dequeued and executed at any time. The very last active sweeper in the sweep phase is responsible for flushing all local cleanup blocks to the full list. It can do this without any synchronization because the next GC can't start yet, so we can be very certain that nobody else will be accessing the local blocks. Cleanup blocks are stored off-heap because the need to be allocated by the sweeper, which is called from heap allocation paths. As a result, the GC treats cleanup blocks as roots, just like finalizer blocks. Flushes to the full list signal to the scheduler that cleanup goroutines should be awoken. Every time the scheduler goes to wake up a cleanup goroutine and there were more signals than goroutines to wake, it then forwards this signal to runtime.AddCleanup, so that it creates another goroutine the next time it is called, up to gomaxprocs goroutines. The signals here are a little convoluted, but exist because the sweeper and the scheduler cannot safely create new goroutines. For #71772. For #71825. Change-Id: Ie839fde2b67e1b79ac1426be0ea29a8d923a62cc Reviewed-on: https://go-review.googlesource.com/c/go/+/650697 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Knyszek <mknyszek@google.com>
2025-05-07runtime: use "bubble" terminology for synctestDamien Neil
We've settled on calling the group of goroutines started by synctest.Run a "bubble". At the time the runtime implementation was written, I was still calling this a "group". Update the code to match the current terminology. Change-Id: I31b757f31d804b5d5f9564c182627030a9532f4a Reviewed-on: https://go-review.googlesource.com/c/go/+/670135 Reviewed-by: Michael Pratt <mpratt@google.com> Auto-Submit: Damien Neil <dneil@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-05-07runtime: print stack traces for bubbled goroutines on synctest deadlockDamien Neil
When synctest.Run panics due to every goroutine in the bubble being blocked, print a stack trace for every goroutine in the bubble. For #67434 Change-Id: Ie751c2ee6fa136930b18f4bee0277ff30da46905 Reviewed-on: https://go-review.googlesource.com/c/go/+/645719 Auto-Submit: Damien Neil <dneil@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-03-24runtime: rename runfinq to runFinalizersAndCleanupsMichael Pratt
Users see this frame in tracebacks and it serves as a hint that what is running here is a finalizer or cleanup. But runfinq is a rather dense name. We can give it a more obvious name to help users realize what it is. For #73011. Change-Id: I6a6a636ce9a493fd00d4b4c60c23f2b1c96d3568 Reviewed-on: https://go-review.googlesource.com/c/go/+/660296 Auto-Submit: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2025-03-24runtime: always show runfinq in tracebackMichael Pratt
Today, runtime.runfinq is hidden whenever runtime frames are hidden. However this frame serves as a hint that this goroutine is running finalizers, which is otherwise unclear, but can be useful when debugging issues with finalizers. Fixes #73011. Change-Id: I6a6a636cb63951fbe1fefc3554fe9cea5d0a0fb6 Reviewed-on: https://go-review.googlesource.com/c/go/+/660295 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2024-11-19internal/synctest: new package for testing concurrent codeDamien Neil
Add an internal (for now) implementation of testing/synctest. The synctest.Run function executes a tree of goroutines in an isolated environment using a fake clock. The synctest.Wait function allows a test to wait for all other goroutines within the test to reach a blocking point. For #67434 For #69687 Change-Id: Icb39e54c54cece96517e58ef9cfb18bf68506cfc Reviewed-on: https://go-review.googlesource.com/c/go/+/591997 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-10-04runtime: use stringslite.CutPrefix in isExportedRuntimeTobias Klauser
Change-Id: I7cbbe3b9a9f08ac98e3e76be7bda2f7df9c61fb3 Reviewed-on: https://go-review.googlesource.com/c/go/+/617915 Auto-Submit: Tobias Klauser <tobias.klauser@gmail.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-09-17runtime: move getcallersp to internal/runtime/sysMichael Pratt
Moving these intrinsics to a base package enables other internal/runtime packages to use them. For #54766. Change-Id: I45a530422207dd94b5ad4eee51216c9410a84040 Reviewed-on: https://go-review.googlesource.com/c/go/+/613261 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2024-09-17runtime: move getcallerpc to internal/runtime/sysMichael Pratt
Moving these intrinsics to a base package enables other internal/runtime packages to use them. For #54766. Change-Id: I0b3eded3bb45af53e3eb5bab93e3792e6a8beb46 Reviewed-on: https://go-review.googlesource.com/c/go/+/613260 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2024-07-23runtime,internal: move runtime/internal/sys to internal/runtime/sysDavid Chase
Cleanup and friction reduction For #65355. Change-Id: Ia14c9dc584a529a35b97801dd3e95b9acc99a511 Reviewed-on: https://go-review.googlesource.com/c/go/+/600436 Reviewed-by: Keith Randall <khr@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Keith Randall <khr@golang.org>
2024-05-29all: document legacy //go:linkname for modules with ≥100 dependentsRuss Cox
For #67401. Change-Id: I015408a3f437c1733d97160ef2fb5da6d4efcc5c Reviewed-on: https://go-review.googlesource.com/c/go/+/587598 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Russ Cox <rsc@golang.org>
2024-05-17runtime: make use of stringslite.{HasPrefix, HasSuffix}Jes Cok
Change-Id: I7461a892e1591e3bad876f0a718a99e6de2c4659 Reviewed-on: https://go-review.googlesource.com/c/go/+/585435 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
2024-03-25runtime: migrate internal/atomic to internal/runtimeAndy Pan
For #65355 Change-Id: I65dd090fb99de9b231af2112c5ccb0eb635db2be Reviewed-on: https://go-review.googlesource.com/c/go/+/560155 Reviewed-by: David Chase <drchase@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ibrahim Bazoka <ibrahimbazoka729@gmail.com> Auto-Submit: Emmanuel Odeke <emmanuel@orijtech.com>
2024-03-15runtime: allow omitting virtual PCs from runtime.CallersFrames inputRuss Cox
This makes CL 561635's test pass without any changes to the traceback textual format. The test in this CL is copied identically from CL 561635. Change-Id: I5130abdfefd9940f98f20c283cca6cd159e37617 Reviewed-on: https://go-review.googlesource.com/c/go/+/571798 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2024-03-14runtime: revert "traceback: include pc=0x%x for inline frames"Russ Cox
This reverts commit 643d816c8b43 (CL 561635). Reason for revert: This works for telemetry but broke various other properties of the tracebacks as well as some programs that read tracebacks. We should figure out a solution that works for all uses, and in the interim we should not be making telemetry work at the cost of breaking other, existing valid uses. See #65761 for details. Change-Id: I467993ae778887e5bd3cca4c0fb54e9d44802ee1 Reviewed-on: https://go-review.googlesource.com/c/go/+/571797 Auto-Submit: Russ Cox <rsc@golang.org> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2024-02-08runtime: traceback: include pc=0x%x for inline framesAlan Donovan
Crash monitoring tools may parse the PC values and feed them to CallersFrames, which does not run the inline unwinder, since Callers already did so. So, the GOTRACEBACK=system output must also include PC values even for inlined frames. (The actual values are just marker NOP instructions, but that isn't important.) This CL also includes a test that the PC values can be parsed out of the crash report and fed to CallersFrames to yield a sensible result. (The logic is a distillation of the x/telemetry crashmonitor.) The previously printed PCs were in fact slightly wrong for frames containing inlined calls: instead of the virtual CALL instruction (a NOP) to the first inlined call, it would display the PC of the CALL in the innermost inlined function. Change-Id: I64a06771fc191ba16c1383b8139b714f4f299703 Reviewed-on: https://go-review.googlesource.com/c/go/+/561635 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Alan Donovan <adonovan@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2024-01-30runtime: print exported methods from the runtime in tracebacksKeith Randall
We currently suppress runtime frames in tracebacks, except for exported functions. This CL also prints exported methods of exported types in tracebacks, for consistency. Change-Id: Ic65e7611621f0b210de5ae0c02b9d0a044f39fd6 Reviewed-on: https://go-review.googlesource.com/c/go/+/507736 Reviewed-by: Cherry Mui <cherryyz@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Emmanuel Odeke <emmanuel@orijtech.com>
2024-01-23cmd/compile/internal/ssagen,runtime: merge trace consts into internal/abiqiulaidongfeng
For #59670 Change-Id: Iec85ee7312bb566b3f1224424f7d27bf4e408b13 GitHub-Last-Rev: c620abf9673e166505821d75717e820776abc302 GitHub-Pull-Request: golang/go#64905 Reviewed-on: https://go-review.googlesource.com/c/go/+/553295 Reviewed-by: Keith Randall <khr@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-12-06iter, runtime: add coroutine supportRuss Cox
The exported API is only available with GOEXPERIMENT=rangefunc. This will let Go 1.22 users who want to experiment with rangefuncs access an efficient implementation of iter.Pull and iter.Pull2. For #61897. Change-Id: I6ef5fa8f117567efe4029b7b8b0f4d9b85697fb7 Reviewed-on: https://go-review.googlesource.com/c/go/+/543319 Reviewed-by: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2023-11-16runtime: print g pointer in crash stack dumpCherry Mui
When debugging a runtime crash with a stack trace, sometimes we have the g pointer in some places (e.g. as an argument of a traceback function), but the g's goid in some other places (the stack trace of that goroutine), which are usually not easy to match up. This CL makes it print the g pointer. This is only printed in crash mode, so it doesn't change the usual user stack trace. Change-Id: I19140855bf020a327ab0619b665ec1d1c70cca8a Reviewed-on: https://go-review.googlesource.com/c/go/+/541996 Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2023-10-12runtime: don't print "unexpected SPWRITE" when printing tracebackCherry Mui
The system stack often starts with a stack transition function like "systemstack" or "mcall", which is marked as SPWRITE. When unwinding a system stack for printing, we want the traceback stop at the stack switching frame, but not print the "unexpected SPWRITE" message. Previously before CL 525835, we don't print the "unexpected SPWRITE" message if unwindPrintErrors is set, i.e. printing a stack trace. This CL restores this behavior. Another possibility is not printing the message only on the system stack. We don't expect a stack transition function to appear in a user G. Change-Id: I173e89ead2cd4fbf1f0f8cca225f28718b5baebe Reviewed-on: https://go-review.googlesource.com/c/go/+/531815 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2023-09-18all: clean unnecessary castsJes Cok
Run 'unconvert -safe -apply' (https://github.com/mdempsky/unconvert) Change-Id: I24b7cd7d286cddce86431d8470d15c5f3f0d1106 GitHub-Last-Rev: 022e75384c08bb899a8951ba0daffa0f2e14d5a7 GitHub-Pull-Request: golang/go#62662 Reviewed-on: https://go-review.googlesource.com/c/go/+/528696 Auto-Submit: Ian Lance Taylor <iant@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2023-09-06runtime: ignore SPWrite on innermost traceback frameAustin Clements
Prior to CL 458218, gentraceback ignored the SPWrite function flag on the innermost frame when doing a precise traceback on the assumption that precise tracebacks could only be started from the morestack prologue, and that meant that the innermost function could not have modified SP yet. CL 458218 rearranged this logic a bit and unintentionally lost this particular case. As a result, if traceback starts in an assembly function that modifies SP (either as a result of stack growth or stack scanning during a GC preemption), traceback stop at the SPWrite function and then crash with "traceback did not unwind completely". Fix this by restoring the earlier special case for when the innermost frame is SPWrite. This is a fairly minimal change that should be easy to backport. I think a more robust change would be to encode this per-PC in the spdelta table, so it would be clear that we're unwinding from the morestack prologue and wouldn't rely on a complicated and potentially fragile set of conditions. Fixes #62326. Change-Id: I34f38157631890d33a79d0bd32e32c0fcc2574e4 Reviewed-on: https://go-review.googlesource.com/c/go/+/525835 LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Auto-Submit: Austin Clements <austin@google.com> Reviewed-by: Michael Pratt <mpratt@google.com>
2023-08-21runtime: drop stack-allocated pcvalueCachesAustin Clements
Now that pcvalue keeps its cache on the M, we can drop all of the stack-allocated pcvalueCaches and stop carefully passing them around between lots of operations. This significantly simplifies a fair amount of code and makes several structures smaller. This series of changes has no statistically significant effect on any runtime Stack benchmarks. I also experimented with making the cache larger, now that the impact is limited to the M struct, but wasn't able to measure any improvements. This is a re-roll of CL 515277 Change-Id: Ia27529302f81c1c92fb9c3a7474739eca80bfca1 Reviewed-on: https://go-review.googlesource.com/c/go/+/520064 Auto-Submit: Austin Clements <austin@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Austin Clements <austin@google.com>
2023-08-07Revert "runtime: drop stack-allocated pcvalueCaches"Austin Clements
This reverts CL 515277 Change-Id: Ie10378eed4993cb69f4a9b43a38af32b9d743155 Reviewed-on: https://go-review.googlesource.com/c/go/+/516855 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Matthew Dempsky <mdempsky@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Austin Clements <austin@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2023-08-07runtime: drop stack-allocated pcvalueCachesAustin Clements
Now that pcvalue keeps its cache on the M, we can drop all of the stack-allocated pcvalueCaches and stop carefully passing them around between lots of operations. This significantly simplifies a fair amount of code and makes several structures smaller. This series of changes has no statistically significant effect on any runtime Stack benchmarks. I also experimented with making the cache larger, now that the impact is limited to the M struct, but wasn't able to measure any improvements. Change-Id: I4719ebf347c7150a05e887e75a238e23647c20cd Reviewed-on: https://go-review.googlesource.com/c/go/+/515277 TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Austin Clements <austin@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Carlos Amedee <carlos@golang.org>
2023-07-04runtime: have ReadMemStats do a nil check before switching stacksKeith Randall
This gives the user a better stack trace experience. No need to expose them to runtime.systemstack and friends. Fixes #61158 Change-Id: I4f423f82e54b062773067c0ae64622e37cb3948b Reviewed-on: https://go-review.googlesource.com/c/go/+/507755 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Keith Randall <khr@google.com>
2023-05-05cmd/link, runtime: include full symbol name for generic functions in runtime ↵Cherry Mui
table For generic functions and methods, we replace the instantiated shape type parameter name to "...", to make the function name printed in stack traces looks more user friendly. Currently, this is done in the binary's runtime func table at link time, and the runtime has no way to access the full symbol name. This causes the profile to also contain the replaced name. For PGO, this also cause the compiler to not be able to find out the original fully instantiated function name from the profile. With this CL, we change the linker to record the full name, and do the name substitution at run time when a printing a function's name in traceback. For #58712. Change-Id: Ia0ea0989a1ec231f3c4fbf59365c9333405396c6 Reviewed-on: https://go-review.googlesource.com/c/go/+/491677 Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-04-21internal/abi, runtime, cmd: merge PCDATA_* and FUNCDATA_* consts into ↵Austin Clements
internal/abi We also rename the constants related to unsafe-points: currently, they follow the same naming scheme as the PCDATA table indexes, but are not PCDATA table indexes. For #59670. Change-Id: I06529fecfae535be5fe7d9ac56c886b9106c74fd Reviewed-on: https://go-review.googlesource.com/c/go/+/485497 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
2023-04-21internal/abi, runtime, cmd: merge funcFlag_* consts into internal/abiAustin Clements
For #59670. Change-Id: Ie784ba4dd2701e4f455e1abde4a6bfebee4b1387 Reviewed-on: https://go-review.googlesource.com/c/go/+/485496 Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Austin Clements <austin@google.com> Auto-Submit: Austin Clements <austin@google.com>
2023-04-21internal/abi, runtime, cmd: merge funcID_* consts into internal/abiAustin Clements
For #59670. Change-Id: I517e97ea74cf232e5cfbb77b127fa8804f74d84b Reviewed-on: https://go-review.googlesource.com/c/go/+/485495 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com>
2023-04-06runtime: fix typo in traceback.goKaiya
Change-Id: I3515453c3b4310b9fc635324d75c872a01501604 Reviewed-on: https://go-review.googlesource.com/c/go/+/482735 Auto-Submit: Michael Knyszek <mknyszek@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com>
2023-03-21runtime: for deep stacks, print both the top 50 and bottom 50 framesAustin Clements
This is relatively easy using the new traceback iterator. Ancestor tracebacks are now limited to 50 frames. We could keep that at 100, but the fact that it used 100 before seemed arbitrary and unnecessary. Fixes #7181 Updates #54466 Change-Id: If693045881d84848f17e568df275a5105b6f1cb0 Reviewed-on: https://go-review.googlesource.com/c/go/+/475960 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
2023-03-15runtime: fix callee tracking in traceback printingAustin Clements
In CL 466099, we accidentally stopped tracking callees while unwinding inlined frames during traceback printing. The effect is that if you have a call stack like: f -> wrapper -> inlined into wrapper -> panic when considering whether to print the frame for "wrapper", we'll think that wrapper called panic, rather than the inlined function. Fix this in the traceback code and add a test. Change-Id: I30ec836cc316846ce93de94e28a650e23dca184e Reviewed-on: https://go-review.googlesource.com/c/go/+/476579 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
2023-03-10runtime: delete gentracebackAustin Clements
Printing is the only remaining functionality of gentraceback. Move this into the traceback printing code and eliminate gentraceback. This lets us simplify the logic, which fixes at least one minor bug: previously, if inline unwinding pushed the total printed count over _TracebackMaxFrames, we would print extra frames and then fail to print "additional frames elided". The cumulative performance effect of the series of changes starting with "add a benchmark of Callers" (CL 472956) is: goos: linux goarch: amd64 pkg: runtime cpu: Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz │ baseline │ unwinder │ │ sec/op │ sec/op vs base │ Callers/cached-48 1.464µ ± 1% 1.684µ ± 1% +15.03% (p=0.000 n=20) Callers/inlined-48 1.391µ ± 1% 1.536µ ± 1% +10.42% (p=0.000 n=20) Callers/no-cache-48 10.50µ ± 1% 11.11µ ± 0% +5.82% (p=0.000 n=20) StackCopyPtr-48 88.74m ± 1% 81.22m ± 2% -8.48% (p=0.000 n=20) StackCopy-48 80.90m ± 1% 70.56m ± 1% -12.78% (p=0.000 n=20) StackCopyNoCache-48 2.458m ± 1% 2.209m ± 1% -10.15% (p=0.000 n=20) StackCopyWithStkobj-48 26.81m ± 1% 25.66m ± 1% -4.28% (p=0.000 n=20) geomean 518.8µ 512.9µ -1.14% The performance impact of intermediate CLs in this sequence varies a lot as we went through many refactorings. The slowdown in Callers comes primarily from the introduction of unwinder because that doesn't get inlined and results in somewhat worse code generation in code that's extremely hot in those microbenchmarks. The performance gains on stack copying come mostly from replacing callbacks with direct use of the unwinder. Updates #54466. Fixes #32383. Change-Id: I4970603b2861633eecec30545e852688bc7cc9a4 Reviewed-on: https://go-review.googlesource.com/c/go/+/468301 Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-03-10runtime: new API for filling PC traceback buffersAustin Clements
Currently, filling PC traceback buffers is one of the jobs of gentraceback. This moves it into a new function, tracebackPCs, with a simple API built around unwinder, and changes all callers to use this new API. Updates #54466. Change-Id: Id2038bded81bf533a5a4e71178a7c014904d938c Reviewed-on: https://go-review.googlesource.com/c/go/+/468300 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Austin Clements <austin@google.com>
2023-03-10runtime: move cgo traceback into unwinderAustin Clements
Currently, gentraceback's loop ends with a call to tracebackCgoContext to process cgo frames. This requires spreading various parts of the printing and pcbuf logic across these two functions. Clean this up by moving cgo unwinding into unwinder and then lifting the printing and pcbuf logic from tracebackCgoContext into gentraceback along with the other printing and pcbuf logic. Updates #54466. Change-Id: Ic71afaa5ae110c0ea5be9409e267e4284e36a8c9 Reviewed-on: https://go-review.googlesource.com/c/go/+/468299 Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-03-10runtime: simplify traceback PC back-up logicAustin Clements
Updates #54466. Change-Id: If070cf3f484e3e02b8e586bff466e0018b1a1845 Reviewed-on: https://go-review.googlesource.com/c/go/+/468298 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-03-10runtime: replace all callback uses of gentraceback with unwinderAustin Clements
This is a really nice simplification for all of these call sites. It also achieves a nice performance improvement for stack copying: goos: linux goarch: amd64 pkg: runtime cpu: Intel(R) Xeon(R) CPU E5-2690 v3 @ 2.60GHz │ before │ after │ │ sec/op │ sec/op vs base │ StackCopyPtr-48 89.25m ± 1% 79.78m ± 1% -10.62% (p=0.000 n=20) StackCopy-48 83.48m ± 2% 71.88m ± 1% -13.90% (p=0.000 n=20) StackCopyNoCache-48 2.504m ± 2% 2.195m ± 1% -12.32% (p=0.000 n=20) StackCopyWithStkobj-48 21.66m ± 1% 21.02m ± 2% -2.95% (p=0.000 n=20) geomean 25.21m 22.68m -10.04% Updates #54466. Change-Id: I31715b7b6efd65726940041d3052bb1c0a1186f3 Reviewed-on: https://go-review.googlesource.com/c/go/+/468297 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
2023-03-10runtime: implement traceback iteratorAustin Clements
Currently, all stack walking logic is in one venerable, large, and very, very complicated function: runtime.gentraceback. This function has three distinct operating modes: printing, populating a PC buffer, or invoking a callback. And it has three different modes of unwinding: physical Go frames, inlined Go frames, and cgo frames. It also has several flags. All of this logic is very interwoven. This CL reimplements the monolithic gentraceback function as an "unwinder" type with an iterator API. It moves all of the logic for stack walking into this new type, and gentraceback is now a much-simplified wrapper around the new unwinder type that still implements printing, populating a PC buffer, and invoking a callback. Follow-up CLs will replace uses of gentraceback with direct uses of unwinder. Exposing traceback functionality as an iterator API will enable a lot of follow-up work such as simplifying the open-coded defer implementation (which should in turn help with #26813 and #37233), printing the bottom of deep stacks (#7181), and eliminating the small limit on CPU stacks in profiles (#56029). Fixes #54466. Change-Id: I36e046dc423c9429c4f286d47162af61aff49a0d Reviewed-on: https://go-review.googlesource.com/c/go/+/458218 Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Austin Clements <austin@google.com>
2023-03-10runtime: replace cgoCtxt slice with index in tracebackAustin Clements
Currently, gentraceback consumes the gp.cgoCtxt slice by copying the slice header and then sub-slicing it as it unwinds. The code for this is nice and clear, but we're about to lift this state into a structure and mutating it is going to introduce write barriers that are disallowed in gentraceback. This CL replaces the mutable slice header with an index into gp.cgoCtxt. For #54466. Change-Id: I6b701bb67d657290a784baaca34ed02d8247ede2 Reviewed-on: https://go-review.googlesource.com/c/go/+/466863 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-03-10runtime: use inlineUnwinderAustin Clements
This converts all places in the runtime that perform inline expansion to use the new inlineUnwinder abstraction. For #54466. Change-Id: I48d996fb6263ed5225bd21d30914a27ae434528d Reviewed-on: https://go-review.googlesource.com/c/go/+/466099 Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Michael Pratt <mpratt@google.com>
2023-03-10runtime: use srcFunc for showframeAustin Clements
Since srcFunc can represent information for either an real text function or an inlined function, this means we no longer have to synthesize a fake _func just to call showframe on an inlined frame. This is cleaner and also eliminates the one case where _func values live in the heap. This will let us mark them NotInHeap, which will in turn eliminate pesky write barriers in the traceback rewrite. For #54466. Change-Id: Ibf5e24d01ee4bf384c825e1a4e2922ef444a438e Reviewed-on: https://go-review.googlesource.com/c/go/+/466097 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-03-10runtime: resolve caller funcInfo after processing current frameAustin Clements
Currently, gentraceback resolves the funcInfo of the caller prior to processing the current frame (calling the callback, printing it, etc). As a result, if this lookup fails in a verbose context, it will print the failure before printing the frame that it's already resolved. To fix this, move the resolution of LR to a funcInfo to after current frame processing. This also has the advantage that we can reduce the scope of "flr" (the caller's funcInfo) to only the post-frame part of the loop, which will make it easier to stack-rip gentraceback into an iterator. For #54466. Change-Id: I8be44d4eac598a686c32936ab37018b8aa97c00b Reviewed-on: https://go-review.googlesource.com/c/go/+/458217 TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com>
2023-03-10runtime: eliminate waspanic from gentracebackAustin Clements
gentraceback also tracks the funcID of the callee, which is more general. Fix this up to happen in all cases and eliminate waspanic in favor of checking the funcID of the caller. For #54466. Change-Id: Idc98365a6f05022db18ddcd5b3ed8684a6872a88 Reviewed-on: https://go-review.googlesource.com/c/go/+/458216 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-03-10runtime: don't track stack separately in gentracebackAustin Clements
Currently, gentraceback keeps a copy of the stack bounds of the stack it's walking in the "stack" variable. Now that "gp" always refers to the G whose stack it's walking, we can simply use gp.stack instead of keeping a separate copy. For #54466. Change-Id: I68256e5dff6212cfcf14eda615487e66a92d4914 Reviewed-on: https://go-review.googlesource.com/c/go/+/458215 Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Felix Geisendörfer <felix.geisendoerfer@datadoghq.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2023-02-21runtime: record parent goroutine ID, and print it in stack tracesNick Ripley
Fixes #38651 Change-Id: Id46d684ee80e208c018791a06c26f304670ed159 Reviewed-on: https://go-review.googlesource.com/c/go/+/435337 Run-TryBot: Nick Ripley <nick.ripley@datadoghq.com> Reviewed-by: Ethan Reesor <ethan.reesor@gmail.com> Auto-Submit: Michael Pratt <mpratt@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-11-07runtime: fix a few function names on commentscui fliter
Change-Id: I9ef4898d68dfd06618c0bd8e23f81a1d2c77a836 Signed-off-by: cui fliter <imcusg@gmail.com> Reviewed-on: https://go-review.googlesource.com/c/go/+/447460 Auto-Submit: Michael Pratt <mpratt@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Matthew Dempsky <mdempsky@google.com> Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Michael Pratt <mpratt@google.com>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 13:35:11 +0000