/ go Public
runtime: improve the "best effort" of the execution tracer's CPU sample delivery #52674
Issues related to the Go compiler and/or runtime.
Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
The work in https://go.dev/cl/400795 (proposed for the Go 1.19 cycle) to add CPU profile samples to the execution tracer's output relies on the process generating at least a modest stream of other traceable events. If the process's goroutines as a group use more than 19 thread-seconds of CPU time before any individual P flushes a traceBuf (or before tracing ends), the profiling buffer will overflow and (silently) drop records before the goroutine calling
runtime.ReadTracewakes up to drain it.
There may be a better way to move profile samples from the profBuf into traceBufs (such as launching a goroutine to drain the profBuf).
The text was updated successfully, but these errors were encountered: