Accepted proposal: a goroutine leak profile in the Go standard library

Accepted proposal: a goroutine leak profile in the Go standard library | Redowan's ReflectionsSkip to content

Go 1.27 is getting a goroutine leak detector in runtime/pprof. The proposal was accepted in April. A few common goroutine leaks # A goroutine leaks when it blocks on a channel or lock that nothing will ever release, so it lingers for the life of the process. I’ve been using uber-go/goleak to catch them in tests. One is an early return that strands a sender, which I covered in Early return and goroutine leak . It looks like this: func run(tasks []func() error) error { errs := make(chan error) // unbuffered var wg sync.WaitGroup for _, task := range tasks { wg.Go(func() { errs task() }) // (1) for range tasks { if err := errs; err != nil { return err // (2) wg.Wait() return nil

Here: (1) each task sends its result on the unbuffered channel through wg.Go (2) the first error returns early, so the tasks still queued to send block forever Giving errs a buffer big enough for every task, or draining all the results before returning, keeps the sends from blocking. A related leak shows up when you send a request to several replicas and keep only the first answer: func replicate(replicas []func() string) string { results := make(chan string) // unbuffered for _, r := range replicas { go func() { results r() }() // (1) return results // (2)

Here: (1) every replica races to send its answer on the unbuffered channel (2) the first answer returns, and the slower replicas block forever on their sends Same as before, a buffer sized for every replica lets the slower ones send and exit. Another is a forgotten close: func stream(work []int) { out := make(chan int) go func() { for v := range out { // (1) handle(v) }() for _, v := range work { out v // (2) no close(out)

Here: (1) the range keeps pulling from out until it’s closed (2) stream returns without close(out), so the range never ends and the goroutine leaks The fix is to close(out) after the last send, which ends the range and lets the goroutine return. They’re obvious once you spot them, but easy to let slip past under an early return or once the surrounding code grows. goleak catches them in tests. In production you’ve got the regular /debug/pprof/goroutine profile. It shows what each goroutine is blocked on, not whether it will ever unblock, so you’re guessing which are stuck for good and which are just idle. This list is nowhere near exhaustive, and not every leak is in your own code. A dependency, or one of its transitive deps, can leak one too. Uber catalogued the patterns across its Go monorepo The stdlib leak profile can now find them # It came out of Uber, the same place as goleak, and was designed by Vlad Saioc and Milind Chabbi. The detection rides on the garbage collector . A goroutine is leaked when it’s blocked on a channel or lock that no runnable goroutine can reach, directly or through another goroutine a runnable one could unblock. Nothing can ever wake it. The GC flags it. Note Read that as a reachability test. If a goroutine is blocked on primitive P, and P is unreachable from any runnable goroutine or from any goroutine those runnable ones could unblock, then P cannot be unblocked. The goroutine can never wake up.

goleak and the profile answer different questions: goleakgoroutineleak profileAskswhat’s still running you didn’t expectwhat can never run againHow it decidesa snapshot, no proofa reachability proof, via the GCWorks intests, at teardowna live processFalse positivesyes, on a live servernone, only provably stuck goroutinesThe split is about where each one runs. At a test’s teardown nothing should be left running. Handing back whatever’s there is exactly what you want from goleak. A live server is the opposite. Most of its goroutines are blocked on purpose, waiting for the next request, and goleak can’t tell those from a real leak. The profile proves it instead. It starts from the goroutines that can still run, follows what they can reach, and rescues any blocked goroutine whose channel or lock is still in play. Whatever’s left has nothing that could ever touch it. It’s stuck for good. Uber had already tried in-production leak detection with a sampling tool, but sampling flags by heuristic and turns up false alarms. The GC pass reports only goroutines it can prove are stuck. That’s the no false positives guarantee. The profile ships without goleak’s VerifyNone(t) or VerifyTestMain(m). The test section shows how to roll your own. The API is tiny. There’s no new type or function, just a profile named goroutineleak. It ships registered, and the standard pprof tooling reads it like any other profile. You can pull the profile in the usual four ways # Note For now the profile is behind a build flag. Run the examples below with GOEXPERIMENT=goroutineleakprofile, or pprof.Lookup("goroutineleak") returns nil. Go 1.27 will make it generally...

Accepted proposal: a goroutine leak profile in the Go standard library

Related Articles

Apple WWDC 2026 Livestream

Claude Fable 5

US Government directive to suspend access to Fable 5 and Mythos 5

Is AI ruining our skills? Early results are in – and they're not good

German ruling declares Google liable for false answers in AI Overviews