Go 'panic: runtime error: invalid memory address or nil pointer dereference' with '[signal SIGSEGV: segmentation violation]': how do I find the nil value and fix it?

Cause: The program followed a pointer whose value is nil. The Go spec says evaluating *x for a nil pointer, or selecting a field through one, causes a run-time panic. Common sources: a function returned (nil, err) and the error was ignored; a struct pointer field that was never initialised; a method called on a nil receiver that then touches its fields; a nil interface or nil func value being called; and the classic typed-nil-in-interface case described in the Go FAQ, where an error-returning function hands back a nil *MyError and the caller's err != nil check is true. Fix (best first): 1. Read the stack trace under the panic line. The first frame that is in your own code (file:line) is where the nil value was used. Look at every pointer, interface or func value on that line. 2. Check errors before using results: if err != nil { return err } immediately after the call that returned the pointer. 3. Initialise what you use: construct structs with &T{...} or a constructor, and create nested pointer fields before writing through them. 4. Where nil is a valid state, test for it explicitly (if p == nil) or make methods safe for a nil receiver. 5. If a function returns the error interface, return a literal nil on success, never a typed nil pointer variable. Declare return types as error, not as a concrete pointer type. 6. Do not wrap everything in recover() to hide it. Recover only at boundaries such as a request handler, log the stack, and still fix the cause. Note that reading from a nil map is fine but writing to one is a separate run-time panic (assignment to entry in nil map): create it with make. Verify: Re-run the failing path or a test that feeds the nil case and confirm no panic. Run go vet ./... and, if you use it, a nil-aware linter in CI. Sources: https://go.dev/ref/spec https://go.dev/doc/faq