cmd/trace: show end stack traces

[felixge]

Go version

go version devel go1.24-733df2bc0a 2024-11-25 02:23:41 +0000 darwin/arm64

Output of go env in your module/workspace:

n/a

What did you do?

I generated an execution trace for a simple Go program that has a single goroutine that runs for 10ms on CPU followed by 10ms of sleep in a loop.

What did you see happen?

Clicking on the first three goroutine spans, I see:

Showing only the start stack traces also makes it impossible to see the last stack trace produced by a goroutine.

What did you expect to see?

Showing both start and end stack traces would make it much easier to understand the trace:

update: I realized this is not just a "nice to have" but actually a regression compared to go1.22, see comment below.

cc @mknyszek @prattmic @nsrip-dd - CL for this is submitted below

[gabyhelp]

Related Issues

• runtime/trace: using cgo introduces goroutine with empty stack #61037
• cmd/trace: go tool trace mishandles goroutine that extends beyond the current span. #21911
• runtime: partial stack trace should print that it's partial #7180 (closed)
• cmd/trace/v2: goroutine analysis page doesn't identify goroutines consistently #65574 (closed)
• runtime: stack traces of endless recursion should print top and bottom #7181 (closed)
• runtime: stack traces don't include the parent goroutine #69190 (closed)
• cmd/trace: visualize time taken by syscall #57307 (closed)
• runtime: GOTRACEBACK=crash doesn't print user stack for threads on system stack #19494 (closed)

Related Code Changes

• runtime: stack traces of endless recursion now print top and bottom
• runtime: stack traces of endless recursion now print top and bottom

_{(Emoji vote if this was helpful or unhelpful; more detailed feedback welcome in this discussion.)}

[gopherbot]

Change https://go.dev/cl/631895 mentions this issue: cmd/trace: also show end stack traces

[felixge]

I just realized that this also seems to be a regression compared to go1.22. It seems like the old behavior was to always show the end stack trace, and only to show the start stack trace when the goroutine was created (?), see screenshots below. (I re-executed the program in go1.22, but the 3rd screenshot also shows a span that was preceeded by a short execution that got preempted).

So maybe the case can be made to include this into go1.24 despite the freeze and potentially even a backport to go1.23?

[GoVeronicaGo]

cc: @golang/runtime

[prattmic]

Since this is a regression and very simple, I personally think it would be OK to backport.

[felixge]

@gopherbot please consider this for backport to 1.23, it’s a regression.

[gopherbot]

Backport issue(s) opened: #70592 (for 1.23).

Remember to create the cherry-pick CL(s) as soon as the patch is submitted to master, according to https://go.dev/wiki/MinorReleases.