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: support for cgo pprof is currently heavily Linux-dependent #24545

tenortim opened this issue Mar 26, 2018 · 3 comments


Copy link

@tenortim tenortim commented Mar 26, 2018

What version of Go are you using (go version)?

go version go1.10 freebsd/amd64

Does this issue reproduce with the latest release?


What operating system and processor architecture are you using (go env)?


As suggested in CL 93875 "After this CL is in it would be worth seeing whether testCgoPprof in runtime/crash_test.go can be enabled for FreeBSD.", I have been looking into what it would take to enable the test. What I'm finding is that all of the cgo pprof tests fail and when I look at the pprof output, it's missing the header that details the executable and libraries, which causes the profile to be incomplete/incorrect.

Following the code, readMapping in runtime/pprof/proto.go is using /proc/self/maps which is Linux-specific. I'm looking for thoughts on how this might be extended to other platforms. It's not obvious that there's any portable equivalent here.

On FreeBSD there are at least two options. Code to parse /proc/curproc/map would be very easy to write based on the existing code, but the downside is that procfs isn't mounted by default on FreeBSD. The libprocstat code would work everywhere, but is sysctl-based and would require a fair bit more work, at least to convert it to Go code rather than relying on an external library.

On OSX, it's completely different again. There are Mach calls to get the info. Sample code can be found at e.g.

Anyway, I'm curious if anybody has any ideas or opinions about this.


This comment has been minimized.

Copy link

@andybons andybons commented Mar 26, 2018

This seems like a better discussion to start on golang-dev@. You can then put together a proposal and refine this issue with concrete plans.

@andybons andybons added this to the Unplanned milestone Mar 26, 2018

This comment has been minimized.

Copy link

@ianlancetaylor ianlancetaylor commented Mar 27, 2018


This comment has been minimized.

Copy link
Contributor Author

@tenortim tenortim commented Mar 27, 2018

Thank you @andybons starting a thread in golang-dev.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
3 participants
You can’t perform that action at this time.