-
Notifications
You must be signed in to change notification settings - Fork 601
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
pprof collection across reflected functions #54
Comments
Thanks for reporting this. Here some investigation notes. Program I used to reproduce:
Running it I can see the stack looks like what it is expected to look like:
and the heap profile file has the 0x47a222 value repeated 5 times too, so the stack frames below the reflection frame are in the profile:
Yet, pprof output seems to have stripped all frames from runtime.call32 and below:
I first thought this could be a symbolization issue, but the addresses of interest symbolize fine through the binary:
|
What happens is that There is the counterpart "keep" pattern list which only includes |
See google#54. Frames under call32/call64 may be user code frames so should be shown to avoid confusing re-attribution of allocations to the calling system frames.
Adding
to the allocSkipRxStr list changes the pprof output to the expected:
The discussion on golang-nuts hasn't been too active so far, so I'll file a Go bug to get it going. |
@aalexand great, thanks for investigating. Glad to hear this might get fixed. |
Filed golang/go#18077. |
This uses https://go-review.googlesource.com/#/c/33635 instead of the previous change to fix google#54.
This uses https://go-review.googlesource.com/#/c/33635 instead of the previous change to fix google#54.
I don't know if this is an actual bug, a documentation bug, or neither but I hit an interesting corner case trying to collect pprof measurements that I wanted to report. While working with https://github.com/urfave/cli I ran into urfave/cli#551 trying to collect pprof data.
Is pprof collection expected to work on code that calls into a reflected function? If so, I don't believe it does so there may be a real bug. If not it would be helpful if the docs mentioned this limitation.
Thanks.
The text was updated successfully, but these errors were encountered: