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.

Sign up for GitHub

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

Jump to bottom

debug/dwarf: memory leak in dwarf parsing, entries remain on heap #72007

Closed
grantseltzer opened this issue Feb 27, 2025 · 3 comments
Closed

debug/dwarf: memory leak in dwarf parsing, entries remain on heap #72007

grantseltzer opened this issue Feb 27, 2025 · 3 comments
Labels
BugReport Issues describing a possible bug in the Go implementation. compiler/runtime Issues related to the Go compiler and/or runtime.

Comments

@grantseltzer
Copy link
Contributor

grantseltzer commented Feb 27, 2025 •
edited
Loading

Go version

1.24.0

Output of go env in your module/workspace:

AR='ar'
CC='gcc'
CGO_CFLAGS='-O2 -g'
CGO_CPPFLAGS=''
CGO_CXXFLAGS='-O2 -g'
CGO_ENABLED='1'
CGO_FFLAGS='-O2 -g'
CGO_LDFLAGS='-O2 -g'
CXX='g++'
GCCGO='gccgo'
GO111MODULE=''
GOARCH='arm64'
GOARM64='v8.0'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/vagrant/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/vagrant/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3313078206=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='arm64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/vagrant/dwarf_repro/go.mod'
GOMODCACHE='/home/vagrant/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/vagrant/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/vagrant/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.24.0.linux-arm64'
GOSUMDB='sum.golang.org'
GOTELEMETRY='local'
GOTELEMETRYDIR='/home/vagrant/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/vagrant/go/pkg/mod/golang.org/toolchain@v0.0.1-go1.24.0.linux-arm64/pkg/tool/linux_arm64'
GOVCS=''
GOVERSION='go1.24.0'
GOWORK=''
PKG_CONFIG='pkg-config'

I also tried downgrading to go 1.23.6 and the same results occur.

What did you do?

Iterating over entries of DWARF using Reader.Next() causes a memory leak where entries remain on the heap even after the returned entry falls out of scope. We've created a simplified test that reproduces this issue. In the test we print memory statistics and show that entry objects remain on the heap.

Run command in README:

https://gist.github.com/grantseltzer/74bb893c51b49647cc5315e04b34c381

(Sorry - would put it in go playground but it wasn't working well for it)

Sample output:

[*] go test -c -gcflags=all="-N -l" -timeout 30s -run ^TestLoadFunctionDefinitions_Heap$ dwarf_repro && ./dwarf_repro.test -test.v
=== RUN   TestLoadFunctionDefinitions_Heap
    dwarf_test.go:66: After 1000 iterations: base alloc = 2026264, final alloc = 196424, diff = 18446744073707721776
    dwarf_test.go:94: Live *dwarf.Entry objects in heap: 11646065993
--- PASS: TestLoadFunctionDefinitions_Heap (17.78s)
PASS

What did you see happen?

dwarf.Entry objects remaining on heap after falling out of scope.

What did you expect to see?

GC to clear these objects off the heap.
@gopherbot gopherbot added the compiler/runtime Issues related to the Go compiler and/or runtime. label Feb 27, 2025
@gabyhelp gabyhelp added the BugReport Issues describing a possible bug in the Go implementation. label Feb 27, 2025
@seankhliao
Copy link
Member

Alloc is a uint64, you're looking at a wraparound from final < base,
You're also reading the pprof sample wrong: you're not filtering by sample type, so you include alloc samples, not just inuse samples.

@seankhliao seankhliao closed this as not planned Won't fix, can't repro, duplicate, stale Feb 27, 2025
@grantseltzer
Copy link
Contributor Author

@seankhliao Thanks for taking a look. Can you look at the updated test code and confirm that this is an accurate way to tell if the memory leak does in fact exist? Once updated based on your feedback it does appear that debug/dwarf is not the source of a memory leak in the code i'm debugging.

@seankhliao
Copy link
Member

I just used the built in -memprofile flag for tests and looked at the resulting profile with pprof.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
BugReport Issues describing a possible bug in the Go implementation. compiler/runtime Issues related to the Go compiler and/or runtime.
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@gopherbot @grantseltzer @seankhliao @gabyhelp