golang-troubleshooting

Run the program with GOTRACEBACK=all to capture full stack traces, then execute go test -race ./... to detect data races. Write a failing test that reproduces the panic before attempting any fix, and trace the data flow back to where the invalid value originated.

Capture a goroutine profile with curl localhost:6060/debug/pprof/goroutine?debug=2 and look for goroutines stuck in chan receive. In tests, use the goleak package to automatically detect leaked goroutines after each test run.

This is the interface nil gotcha: returning a typed nil pointer as an error interface produces a non-nil interface. The fix is to return nil explicitly instead of returning the typed nil variable.

No, recover() only works in the same goroutine where it is deferred. A panic in a child goroutine crashes the entire process, so each goroutine must include its own defer/recover block.

No, pprof endpoints must be protected with authentication and never exposed publicly, since they leak goroutine stacks and memory contents. Run pprof on a separate port or localhost, gate it behind an environment variable, and require basic auth.

Use Delve when you need breakpoint-based stepping through code, inspecting local variables, and switching between goroutines interactively. Use pprof for profiling CPU, heap, mutex, and goroutine behavior in running or production services.