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

Closed
tenortim opened this issue Mar 26, 2018 · 4 comments
Closed

runtime: support for cgo pprof is currently heavily Linux-dependent #24545

tenortim opened this issue Mar 26, 2018 · 4 comments
Labels
FrozenDueToAge WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Milestone

Comments

@tenortim
Copy link
Contributor

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
Copy link
Member

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
@andybons andybons added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Mar 26, 2018
@ianlancetaylor
Copy link
Contributor

CC @rauls5382

@tenortim
Copy link
Contributor Author

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

@mvdan
Copy link
Member

mvdan commented Jun 15, 2021

Closing old issues that still have the WaitingForInfo label where enough details to investigate weren't provided. Feel free to leave a comment with more details and we can reopen.

@mvdan mvdan closed this as completed Jun 15, 2021
@golang golang locked and limited conversation to collaborators Jun 15, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided.
Projects
None yet
Development

No branches or pull requests

5 participants