- Sources: Go blog, HN discussion
- Summary: The new goroutineleak profile type in runtime/pprof is exposed at /debug/pprof/goroutineleak for anyone already running net/http/pprof, covering ground goleak and synctest do not because those run only in tests, and which ordinary goroutine profiles cannot cover because they do not separate a leak from goroutines legitimately blocked in bulk under load. It defines liveness inductively, a goroutine is live if unblocked or if a primitive blocking it is referenced by another live goroutine, then reuses the mark-and-sweep collector by seeding mark roots with only the unblocked goroutines. Coverage is limited to channel operations, blocking select and sync Mutex, RWMutex, WaitGroup and Cond, so file and network IO blocking is never reported, a primitive kept reachable from a global hides its waiters, and the worst case is quadratic in goroutine count per cycle on a daisy chain, which is why the post recommends periodic collection every few hours rather than continuous use. The post is dated 2026-09-02 and the Hacker News thread was created 2026-09-16 with 48 points, so this item predates the page's window. The work comes from Aarhus University, Washington University in St. Louis and Uber.
- Why it matters: Goroutine leaks become diagnosable in a running production service rather than only under test, within the stated limits on which blocking primitives the analysis covers.
send feedback on this story