Hello,
I was playing around with the runtime/pprof memory profiling tool and I believe I have found a memory leak. Now after some investigation, I am a bit confused and am not sure anymore if it is a memory leak, to begin with. (Or some potential weird thing related to the garbage collector)
Consider the following example. (It doesn’t reproduce the error, but is very similar to our own production code.)
https://play.golang.org/p/CgwjgZwm25N
When I investigate with go tool pprof
It shows me that there is still some data allocated in the “inuse_space” sample.
func (req *Request) Init(operation string, oldConfigData string, newConfigData string) *Request {
req.operation = operation
req.oldInfo = NewInfo(oldConfigData) <— note that there is no memory in use here… ?
req.newInfo = NewInfo(newConfigData) <---- here I still have memory in the “inuse_space”
return req
}
I verified that the “functionalCall()” function does return. So this means (at least to my understanding) that the “req” variable should go out of scope and be cleaned up by the garbage collector. But according to the memory profiles, it doesn’t.
I made the conclusion from this, that this would mean: That the “req.newInfo” pointer variable is used/stored somewhere further down the road in the “doSomeThingsToTheRequest()” function.
I then wanted to verify this by modifying the “doSomeThingsToTheRequest()” to use a local copy in any further operations. I expected the memory profiling tool to show that the “localInfo” is now the variable that is leaking memory. But it doesn’t, it is still showing the original variable to still hold memory. (See above…) --> I am confused that what I consider to be a memory leak wasn’t moved.
func doSomeThingsToTheRequest(req *Request){
var localInfo Info
localInfo = *req.newInfo
req.newInfo = &localInfo
fmt.Println(&localReq)
}
Now I am a bit confused about whether this is a memory leak or not.