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

Open
tenortim opened this Issue Mar 26, 2018 · 3 comments

Comments

Projects
None yet
3 participants
@tenortim
Contributor

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?

Yes

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

freebsd/amd64

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. http://www.newosxbook.com/src.jl?tree=listings&file=12-1-vmmap.c

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

@andybons

This comment has been minimized.

Member

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

@ianlancetaylor

This comment has been minimized.

Contributor

ianlancetaylor commented Mar 27, 2018

@tenortim

This comment has been minimized.

Contributor

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