-
Notifications
You must be signed in to change notification settings - Fork 18.4k
Closed
Labels
FrozenDueToAgeNeedsFixThe path to resolution is known, but the work has not been done.The path to resolution is known, but the work has not been done.compiler/runtimeIssues related to the Go compiler and/or runtime.Issues related to the Go compiler and/or runtime.
Description
What version of Go are you using (go version)?
$ go version go version go1.19.5 linux/amd64
Does this issue reproduce with the latest release?
Yes, I got the same result with go 1.20.
What did you do?
I have program:
package main
import (
"os"
"runtime"
"runtime/trace"
)
func main() {
runtime.SetCPUProfileRate(100)
err := trace.Start(os.Stdout)
if err != nil {
panic(err)
}
for i := 0; i < 10000; i++ {
for j := 0; j < 10000; j++ {
_ = i + j
}
}
defer trace.Stop()
}The program provides a trace file as output.
What did you expect to see?
I expect Cpu samples in the trace file will be in the format (as in the source code of trace tool):
EvCPUSample = 49 // CPU profiling sample [timestamp, stack, real timestamp, real P id (-1 when absent), goroutine id]I.e. stack is second, real timestamp is third.
What did you see instead?
Instead, I see the following events in the trace file:
event type: 49, args: [11 1755437435756 0 1 15]
event type: 49, args: [10 1755437928681 0 1 15]
event type: 49, args: [4 1755438251486 0 1 15]
So seems like real timestamp is on the second position, but more essential there is no stack id!
Metadata
Metadata
Assignees
Labels
FrozenDueToAgeNeedsFixThe path to resolution is known, but the work has not been done.The path to resolution is known, but the work has not been done.compiler/runtimeIssues related to the Go compiler and/or runtime.Issues related to the Go compiler and/or runtime.