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

cmd/pprof: Ability to attribute memory usage to different instances of structs #50829

Closed
aditighag opened this issue Jan 26, 2022 · 4 comments
Closed

Comments

@aditighag
Copy link

aditighag commented Jan 26, 2022

I believe the pprof tooling can provide more information to help debug certain memory leak issues. Here is a (simplified) pseudo code to explain what additional information I'm looking for -

type Foo struct {
   c Cache 
}
type Bar struct {
   c Cache
}
s1 Foo
s2 Bar

type (c *Cache) Populate { -----> results in memory leak for s1 but not s2
   
}

Go tool proof (invoked with either inuse_space or inuse_objects would show that memory usage is increasing in the type (c *Cache) Populate, but it would be helpful if the tooling could attribute the memory usage to the different instances - s1 vs s2? While you can argue different design based the pseudo code, the feature request is relevant more generally.

Edit : I think this falls under the "feature request" category, but I'm unable to update the labels.

@rsc
Copy link
Contributor

rsc commented Jan 26, 2022

The tooling does not really work that way. It is attributing allocations to functions that call the allocation routines. It has no idea where that memory goes or what it is held by. I don't see a way to do what you are asking for. A heap dump would show information like that, but we don't have particularly great support for that at the moment.

@aditighag
Copy link
Author

A heap dump would show information like that

Can you elaborate on how one could go about getting the information from heap dumps?

@ianlancetaylor
Copy link
Contributor

A good heap dump will let you trace from a global variable like s1 or s2 to all the memory to which those variables point.

@ianlancetaylor
Copy link
Contributor

I don't see a path forward here, so closing. Please comment if you disagree.

@golang golang locked and limited conversation to collaborators Feb 16, 2023
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

4 participants