Nick Ripley's blog. Programming and other interests.
Go has automatic memory management, but it's still possible to leak memory. Probably the most common kind of leak I've seen is leaking goroutines. You start a goroutine to do some work, but forget to arrange for the goroutine to stop. The goroutine holds on to memory and the garbage collector can't clean it up. This post covers two examples from the Go standard library for doing work in goroutines…
Every now and then, I've run into a tricky Go bug that seems to involve the compiler, runtime, or standard library. Try as I might, I can't reproduce the bug. I've only seen it happen in production. I don't have enough information to diagnose the issue. Sometimes I've wished I could get the runtime to emit some more diagnostics, or just wanted to try out a potential fix from another Go…
Recently I diagnosed and fixed two frame pointer unwinding crashes in Go. The root causes were two flavors of the same problem: buggy assembly code clobbered a frame pointer. By "clobbered" I mean wrote over the value without saving & restoring it. One bug clobberd the frame pointer register. The other bug clobbered a frame pointer saved on the stack. This post explains the bugs, talks a bit about…
This post is about how I investigated a frame pointer unwinding crash in the Go runtime. The bug was specific to 64-bit ARM: asynchronous preemption at a specific instruction, in certain functions, led to a kind of use-after-free bug which caused the runtime execution tracer to crash when collecting a traceback. The Go runtime is low-level, and can be intimidating and mysterious. But digging into…