--- FAIL: TestCPUProfileMultithreadMagnitude (0.42s)
pprof_test.go:123: Running on Linux 4.19.0
--- FAIL: TestCPUProfileMultithreadMagnitude/serial (0.20s)
pprof_test.go:189: Running with 1 workers
pprof_test.go:524: total 9 CPU profile samples collected:
3: 0x15609c (runtime/pprof.cpuHog0:61 runtime/pprof.cpuHog1:55) 0x155fe3 (runtime/pprof.cpuHogger:41) 0x157207 (runtime/pprof.TestCPUProfileMultithreadMagnitude.func184.108.40.206:202) labels: map
6: 0x1560a8 (runtime/pprof.cpuHog0:64 runtime/pprof.cpuHog1:55) 0x155fe3 (runtime/pprof.cpuHogger:41) 0x157207 (runtime/pprof.TestCPUProfileMultithreadMagnitude.func220.127.116.11:202) labels: map
pprof_test.go:595: runtime/pprof.cpuHog1: 9
pprof_test.go:226: compare 154.991ms vs 90ms
pprof_test.go:228: compare got CPU usage reports are too different (limit -40.0%, got -41.9%) want nil
pprof_test.go:126: Failure of this test may indicate that your system suffers from a known Linux kernel bug fixed on newer kernels. See https://golang.org/issue/49065.
FAIL runtime/pprof 7.677s
@prattmic What you said about the x/build/env/linux-arm64/aws/ directory sounds plausible to me, but it also seems possible that the Docker image reuses the host's kernel, and if so then VMImage may be where an update would need to happen to pick up a newer kernel version. Someone else may know more.
I think this the same sort of "short test duration means small sample size means moderate chance of failure when we get unlucky" as we saw in #50232. I fixed that in https://go.dev/cl/393934, "runtime/pprof: rerun magnitude test on failure", but that isn't backported to Go 1.18.
Should we backport that fix to Go 1.18, or live with the noise until it's EOL?