aboutsummaryrefslogtreecommitdiff
path: root/src/cmd/trace/pprof_test.go
AgeCommit message (Collapse)Author
37 hourscmd/trace: pcs overflow would panicWeixie Cui
Fixes #78538 Change-Id: I4bf9add8eab7785504a366331f9ec7c0fb1ca40e GitHub-Last-Rev: 8f3389dd5ac37ea5d7584036c90c353d2d64d7a5 GitHub-Pull-Request: golang/go#78539 Reviewed-on: https://go-review.googlesource.com/c/go/+/762960 Reviewed-by: Florian Lehner <lehner.florian86@gmail.com> Reviewed-by: Michael Knyszek <mknyszek@google.com> Reviewed-by: David Chase <drchase@google.com> LUCI-TryBot-Result: golang-scoped@luci-project-accounts.iam.gserviceaccount.com <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
2025-09-04cmd/trace: don't filter events for profile by whether they have stackMichael Anthony Knyszek
Right now the profile-from-trace code blindly discards events that don't have a stack, but this means it can discard 'end' events for goroutine time ranges that don't have stacks, like when a goroutine exits a syscall. This means we drop stack samples we *do* have, because we correctly already only use the stack trace of the corresponding 'start' event for a time-range-of-interest anyway. This change means that some events will be tracked that have no stack in their start event, but that's fine. It won't end up in the profile anyway because the stack is empty! And the rest of the code appears to be robust to an empty stack already. Thank you to Rhys Hiltner for reporting this issue and for the reproducer, which I have worked into a test for this change. Fixes #74850. Change-Id: I943b97ecf6b82803e4a778a0f83a14473d32254e Reviewed-on: https://go-review.googlesource.com/c/go/+/694156 Reviewed-by: Rhys Hiltner <rhys.hiltner@gmail.com> Reviewed-by: Michael Pratt <mpratt@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Carlos Amedee <carlos@golang.org>