-
Notifications
You must be signed in to change notification settings - Fork 17.8k
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: list comment added extra noise in 1.9beta2 #21023
Comments
CC @matloob |
CC @rauls5382 |
Interestingly, the output displays as expected if the test binary isn't provided to pprof. |
Another data point: this may be a Darwin-specific issue, because I can't reproduce this on my Linux machine. I don't have a Windows machine to test. Same for #21022 (cannot reproduce on Linux). |
This problem is related to poor offline symbolization in Darwin. The reason pprof shows the whole file is because there are samples associated to line 13 (see the 338Mb on the bad output listed above). pprof will print the lines around the samples associated to algOne (between lines 13 and 89 in this file). The Go runtime generates correct symbolized profiles, which is why the problem goes away when the binary isn't specified in the command line. But Go doesn't tag the mappings as fully symbolized, so pprof will attempt to resymbolize them if given a chance (see google/pprof#147 for some relevant discussion). When the binary is specified on the command line, pprof will resymbolize using that binary, and it gets some mangled line numbers in Darwin when dealing with inline functions. Some experiments:
Note how in the bad case we have a single frame with the function name and the filename of olgOne, but the line number that should correspond to bytes.NewBuffer. I would recommend:
|
CL https://golang.org/cl/50430 mentions this issue. |
Now that Go 1.10 symbolizes all profiles, simply never pass the binary to pprof. If any examples show the old two-argument command lines we should update them. If so, please file separate issues. |
What version of Go are you using (
go version
)?go version go1.9beta2 darwin/amd64
What operating system and processor architecture are you using (
go env
)?GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="darwin"
GOOS="darwin"
GOPATH="/Users/bill/code/go"
GORACE=""
GOROOT="/usr/local/go"
GOTOOLDIR="/usr/local/go/pkg/tool/darwin_amd64"
GCCGO="gccgo"
CC="clang"
GOGCCFLAGS="-fPIC -m64 -pthread -fno-caret-diagnostics -Qunused-arguments -fmessage-length=0 -fdebug-prefix-map=/var/folders/_v/4r515ktx08g5yr6dgkxhfyfr0000gn/T/go-build016620058=/tmp/go-build -gno-record-gcc-switches -fno-common"
CXX="clang++"
CGO_ENABLED="1"
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
Code to reproduce the bug?
https://github.com/ardanlabs/gotraining/tree/master/topics/go/profiling/memcpu
What did you do?
$ go test -run none -bench . -benchtime 3s -memprofile mem.out
$ go tool pprof -alloc_space memcpu.test mem.out
(pprof) list algOne
What did I expect?
The new list command is not isolating itself to just the function that matches the regular expression. Showing all the code is a lot of noise.
Also
Showing the source code file is nice but the entire path being listed twice is noise. This would have been better.
The text was updated successfully, but these errors were encountered: