Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime/pprof: TestStackBarrierProfiling too short on freebsd too #13846

Closed
bradfitz opened this issue Jan 6, 2016 · 4 comments
Closed

runtime/pprof: TestStackBarrierProfiling too short on freebsd too #13846

bradfitz opened this issue Jan 6, 2016 · 4 comments
Milestone

Comments

@bradfitz
Copy link
Contributor

bradfitz commented Jan 6, 2016

Should freebsd also be skipped? (part of #13841)

http://build.golang.org/log/a50792aa07a14b6644148e160b9858ff07a5e12f

--- FAIL: TestStackBarrierProfiling (0.51s)
    pprof_test.go:363: subprocess failed with exit status 1:
        --- FAIL: TestStackBarrierProfiling (0.49s)
            pprof_test.go:97: profile too short: [0x0 0x3 0x0 0x2710 0x0 0x0 0x1 0x0]
        FAIL
FAIL
FAIL    runtime/pprof   2.190s
@bradfitz bradfitz added this to the Go1.6 milestone Jan 8, 2016
@aclements
Copy link
Member

FreeBSD has been failing a lot on the dashboard. I thought it had okay timer support, but I'll dig in to it.

@aclements
Copy link
Member

FreeBSD is even worse in some ways. Like other Unixes it can only fire SIGPROF for the process running as of the system tick, but it also only accounts for elapsed itimer time as of the system tick. That is, if a whole bunch of processes run during a quantum, each yielding to the next; the one running at the end of the quantum will be attributed the whole time slice and none of the other processes will record any time elapsed. (This is all based on FreeBSD 10.)

usleep doesn't seem as obviously broken as on some platforms (it doesn't seem to unconditionally give up the whole time slice), but it's definitely not very precise. I'm still figuring out what usleep does.

@aclements
Copy link
Member

usleep also gives up the rest of the time slice on FreeBSD, and maybe two time slices. A usleep(100) loop sleeps for a mean of 2ms with little variance. The test doesn't fail as often on FreeBSD because the default time slice is only 1ms (according to /sbin/sysctl kern.hz), which is less than on the other systems. However, it has the same underlying problem.

@gopherbot
Copy link

CL https://golang.org/cl/18455 mentions this issue.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants