Closed
Description
It appears that Windows also can't do profiles reliably?
https://storage.googleapis.com/go-build-log/5b3db773/windows-amd64-gce_15b35da7.log
--- FAIL: TestStackBarrierProfiling (0.83s)
pprof_test.go:363: subprocess failed with exit status 1:
--- FAIL: TestStackBarrierProfiling (0.45s)
pprof_test.go:97: profile too short: [0x0 0x3 0x0 0x2710 0x0 0x0 0x1 0x0]
FAIL
FAIL
FAIL runtime/pprof 2.519s
ok runtime/trace 6.002s
(part of #13841)
Metadata
Metadata
Assignees
Type
Projects
Relationships
Development
No branches or pull requests
Activity
aclements commentedon Jan 8, 2016
Windows is known to have reduced timer resolution, though it can't have the common Unix problem of only delivering profiling signals after a full time slice because the Windows APIs couldn't express a bug like that.
I don't see any Windows profiling failures on the dashboard. Could this be related to whatever CL produced that failure?
bradfitz commentedon Jan 8, 2016
If you paste the git rev at the top of that failure log into Gerrit, Gerrit redirects you to the CL it was part of: https://go-review.googlesource.com/#/c/18374/ (an HTTP header validation change)
So, no... it was a flake.
alexbrainman commentedon Jan 9, 2016
Go profiler is not using signal on Windows. It is running on a separate dedicated OS thread. The thread is running with THREAD_PRIORITY_HIGHEST to make it as reliable as possible, but ... Also the thread is only started on demand - maybe there is some latency to that when CPU is busy.
Alex
alexbrainman commentedon Jan 9, 2016
Also maybe there is merit to https://go-review.googlesource.com/#/c/11478. @dvyukov said it is not needed, so I abandoned the change.
Alex
gopherbot commentedon Jan 15, 2016
CL https://golang.org/cl/18683 mentions this issue.
runtime/pprof: retry failed tests with longer duration