weak: Pointer may get tiny-allocated and grouped with a cleanup argument or closure, causing a leak

[rogpeppe]

Go version

go version go1.26-devel_29d43df8ab Tue Oct 21 14:49:13 2025 -0700 linux/amd64

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=''
GOAMD64='v1'
GOARCH='amd64'
GOAUTH='netrc'
GOBIN=''
GOCACHE='/home/rogpeppe/.cache/go-build'
GOCACHEPROG=''
GODEBUG=''
GOENV='/home/rogpeppe/.config/go/env'
GOEXE=''
GOEXPERIMENT=''
GOFIPS140='off'
GOFLAGS=''
GOGCCFLAGS='-fPIC -m64 -pthread -Wl,--no-gc-sections -fmessage-length=0 -ffile-prefix-map=/tmp/go-build3305958583=/tmp/go-build -gno-record-gcc-switches'
GOHOSTARCH='amd64'
GOHOSTOS='linux'
GOINSECURE=''
GOMOD='/dev/null'
GOMODCACHE='/home/rogpeppe/src/go/pkg/mod'
GONOPROXY=''
GONOSUMDB=''
GOOS='linux'
GOPATH='/home/rogpeppe/src/go'
GOPRIVATE=''
GOPROXY='https://proxy.golang.org,direct'
GOROOT='/home/rogpeppe/go'
GOSUMDB='sum.golang.org'
GOTELEMETRY='on'
GOTELEMETRYDIR='/home/rogpeppe/.config/go/telemetry'
GOTMPDIR=''
GOTOOLCHAIN='auto'
GOTOOLDIR='/home/rogpeppe/go/pkg/tool/linux_amd64'
GOVCS=''
GOVERSION='go1.26-devel_29d43df8ab Tue Oct 21 14:49:13 2025 -0700'
GOWORK=''
PKG_CONFIG='pkg-config'

What did you do?

I ran this program for a while and then stopped it: https://go.dev/play/p/3mmIoiV7wbJ before it could use all my memory.

What did you see happen?

The resulting CSV file is here: https://gist.github.com/rogpeppe/e5b6a0723f65cbc80bfd4861b593e17e

Here's a visualization:

What did you expect to see?

I'd expect to see the GC kicking in and the number of calls to the cleanup function keeping up with the GC, or at least somewhat.

As it is, the memory usage appears to increase unboundedly and the cleanup calls never seem to happen.

Memory use seems to grow indefinitely without AddCleanup too (with only weak.Make) and with just the AddCleanup but without the weak.Make.

As is, this seems to imply that both weak pointers and AddCleanup aren't really fit for purpose.

Note that it makes no difference if we call runtime.GC in the loop.

[thepudds]

Hi @rogpeppe 👋, I'm curious if you've seen some flavor of this problem in a real program?

That might be an additional data point for Michael K. as he does his initial mental triage, though of course it's excellent to also have the nice minimal reproducer you included.

Also, there can be cases where interacting with the runtime in a tight loop can tickle things in a way that tend not to happen in practice for a real program, though I'm not sure that's true here. (#75848 is an example of that general phenomenon, but that particular example might not apply here).

There is also this in the GC Guide:

• Long running cleanups should create a goroutine to avoid blocking the execution of other cleanups.
• runtime.GC will not wait until cleanups for unreachable objects are executed, only until they are all queued.

... which has some advice, but some chance that might explain part of the behavior you saw with calling runtime.GC manually (maybe).

Finally, you probably saw this in the Go 1.25 release notes (related to #71825):

Cleanup functions scheduled by AddCleanup are now executed concurrently and in parallel, making cleanups more viable for heavy use like the unique package. Note that individual cleanups should still shunt their work to a new goroutine if they must execute or block for a long time to avoid blocking the cleanup queue.

In any event, just some quick reactions -- sorry if any of this is off base.

[thepudds]

That said, maybe this is instead more specific to exactly what you are doing in makeWeak, and/or maybe the fact that the object in question is 8 bytes (int).

[thepudds]

It could be related to object size.

FWIW, running the original program on the playground (https://go.dev/play/p/3mmIoiV7wbJ) yields numbers like:

n,HeapObjects,HeapAlloc,CleanCount
0,96,165968,0
100000,450115,8181592,1
200000,900124,16186888,1
300000,1350130,24188328,1
400000,1800130,32188520,1

If I change it like this (so that the object is > 16 bytes):

func main() {
	fmt.Printf("n,HeapObjects,HeapAlloc,CleanCount\n")
	for i := 0; ; i++ {
-		makeWeak(i)
+		s := S{i, i, i}
+		makeWeak(s)
		if (i % 100000) != 0 {
			continue
		}

I seem to get better numbers on the playground (https://go.dev/play/p/wLGLPlGH2Wa).

Note the CleanCount column grows much bigger, and the HeapObjects column is ~10x lower (~180K at the end instead of ~1.8M).

n,HeapObjects,HeapAlloc,CleanCount
n,HeapObjects,HeapAlloc,CleanCount
0,97,112512,0
100000,515850,10505816,34266
200000,410909,8324808,165303
300000,356587,7828328,241636
400000,151940,3151744,389844
500000,136002,2845008,489908
600000,389882,8111696,548203
700000,446958,9885856,632183
800000,183887,3780448,790178
900000,215602,4458984,877089
1000000,148904,3067648,996736
1100000,177423,3672712,1086079
1200000,103211,2174464,1196722
1300000,150335,3133224,1288363
1400000,198267,4104264,1380795
1500000,319020,6639176,1454766
1600000,186412,3856608,1584424

Sorry for any mistake -- basically just a quick drive-by test.

[thepudds]

Probably final comment from me -- I had thought Michael K. had merged something for ~1.25 to fix the AddCleanup / SetFinalizer limitation for the tiny allocator (objects <= 16 bytes), but maybe he only said it was possible, or maybe I just dreamed it.

The doc for AddCleanup still says:

Note that because cleanups may execute arbitrarily far into the future after an object is no longer referenced, the runtime is allowed to perform a space-saving optimization that batches objects together in a single allocation slot. The cleanup for an unreferenced object in such an allocation may never run if it always exists in the same batch as a referenced object. Typically, this batching only happens for tiny (on the order of 16 bytes or less) and pointer-free objects.

[mknyszek]

Oh boy. I'll take a look.

[mknyszek]

Okay my first thought is that something must be keeping the allocated int values alive. It doesn't make sense that cleanups just wouldn't execute.

[mknyszek]

It definitely has to do with the fact that the int is an int. Rewriting makeWeak(i) to makeWeak(&i) is enough to fix it on my machine.

I think I know what's going on here.

A weak.Pointer, under the hood, is a *atomic.Uintptr. When you create a new weak pointer, you're making an 8-byte tiny allocation that is very likely co-located in the same tiny allocation block as the allocation itself. The GC explicitly keeps the atomic.Uintptr alive, which in turn keeps the object itself alive, too.

The tiny allocator continues to cause problems for anything regarding GC liveness, but I think this is technically (and very unfortunately) WAI.

The only near-term mitigation I can think of is to add this kind of tiny allocation circularity check to GODEBUG=checkfinalizers=1 which already does the same kind of check for cleanups.

[mknyszek]

The other mitigation I can think of is to revive the 8-byte pointer-less size class specifically for weak pointers. That would fix this specific issue with weak pointers, though not any related issues with runtime.AddCleanup.

[mknyszek]

The other mitigation I can think of is to revive the 8-byte pointer-less size class specifically for weak pointers.

I think this is the right fix, so this self-cyclic footgun at least can never happen with weak.Pointer values anymore. I'll work on that.