-
Notifications
You must be signed in to change notification settings - Fork 17.9k
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/pprof: memory profile attributes allocation to import line #23049
Comments
If I view the same memory profile with |
Does this also happen when using go1.10beta1? |
I will try it when I get a chance. Just to be sure, did you mean generating the profile with 1.10 beta or viewing the profile with 1.10 beta? |
Can you give us instructions for how to reproduce the problem ourselves? To answer your question: generating the profile with (now) 1.10.1. |
I got around to reproducing this issue with 1.9.x. I can also confirm that this is fixed in 1.10. Here is some sample code that can show you the bug: package main
import (
"bytes"
"fmt"
"testing"
)
func BenchmarkTestWriteNameValuePairs(b *testing.B) {
m := make(map[string]string)
m["foo"] = "bar"
m["bad"] = "good"
for i := 0; i < b.N; i++ {
b := writeNameValuePairs(m)
fmt.Printf("%d bytes written\n", len(b))
}
}
func writeNameValuePairs(val map[string]string) []byte {
buf := bytes.NewBuffer(make([]byte, 0, 512))
for k, v := range val {
if buf.Len() > 0 {
buf.WriteByte('&')
}
buf.WriteString(k)
buf.WriteByte('=')
buf.WriteString(v)
}
return buf.Bytes()
} When you run it with go 1.9.x, do
With 1.10, you'll see
|
Thanks. If it's fixed in 1.10, we're happy. We aren't going to backport the fix to 1.9. |
SGTM. |
Please answer these questions before submitting your issue. Thanks!
What version of Go are you using (
go version
)?go version go1.9.2 darwin/amd64
Does this issue reproduce with the latest release?
Yes.
What operating system and processor architecture are you using (
go env
)?GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
The profile itself was captured on a Linux docker container, and was viewed on MacOS (both on 1.9.2).
What did you do?
I opened a memory profile in the
--alloc_objects
mode. I listed a function to view its allocation, and it associated the allocation that was meant forbytes.NewBuffer
with an import line in the source that imported thebytes
package. Output from list:I confirmed that the first allocation number (12092676) is indeed caused by
bytes.NewBuffer
by writing a small program to match the allocation numbers from this function.What did you expect to see?
The first allocation number (12092676) to be correctly attributed to the actual line.
What did you see instead?
It was attributed to the import line.
The text was updated successfully, but these errors were encountered: