News for hackers. Stuff that matters.
Re:Fixing a kubelet Memory Leak in Kubernetes 1.36 by compumike on Wednesday July 01, 2026 @03:00PM (#48751599)
It does seem like a serious tripping point.

I took a quick look at "containedctx" and it seems like for this case, it would almost be backwards: it would flag the (not-memory-leaking) struct-stored "status.ctx", but wouldn't flag when there is a stored "status.cancelFn" only (which resulted in the memory leak).

Could Go implement a runtime leaked-context detector, like the data race detector? https://go.dev/doc/articles/race_detector

Re:Fixing a kubelet Memory Leak in Kubernetes 1.36 by cyberax on Wednesday July 01, 2026 @03:08PM (#48751715)
This actually is possible now. Contexts are now garbage-collectible, even if cancel() is not called.

In this case, the cancel() function was preventing the collection. But I think it can be changed to hold a weak reference instead. The overhead is too large to run it normally, but it should be OK for something like the race detector.