SECURITY WARNING: Never run commands you don't understand. Always review code before execution. Use at your own risk.
Go New Added 10 September 2026

Go: panic: runtime error: index out of range [3] with length 3

Go slices are zero indexed, so the valid indexes stop one short of len. The message gives both numbers, and when the index is exactly the length the loop ran one iteration too far; when it is far larger the index came from data, not from the loop, and needs validating before use.

Quick fix

Read the commands before running them. Anything that restarts a service, deletes data or changes permissions should be tried on a non-production system first.

Quick fix
# The panic prints the offending index and the length: read both
go run ./cmd/app 2>&1 | head -20

// Off by one: the last valid index is len-1
for i := 0; i < len(xs); i++ { use(xs[i]) }
for i, x := range xs { use(i, x) }        // safer

// Index taken from input: check before indexing
parts := strings.Split(line, ",")
if len(parts) < 3 {
    return fmt.Errorf("expected 3 fields, got %d: %q", len(parts), line)
}

// Slicing is bounded by cap, indexing by len; append grows, index does not
xs := make([]int, 0, 10)
// xs[0] = 1   // panics: len is 0
xs = append(xs, 1)

# Bounds checks are why this is a panic and not memory corruption
go test -race ./...

How to diagnose Go errors

Go's runtime is unusually good at telling you what went wrong. concurrent map writes and all goroutines are asleep - deadlock! are precise diagnoses rather than vague crashes. The recurring themes are nil zero values that need explicit initialisation (maps, channels, pointers inside interfaces), unsynchronised shared state, and contexts that are cancelled upstream.

If the quick fix above does not resolve it, work through these steps. They apply to this whole class of error, not just to this one message, which is usually what saves the time.

  1. Run tests and, where possible, production builds under the race detector: go test -race ./.... It finds data races that are invisible under normal execution.
  2. Read the full panic output. Go prints every goroutine's stack, and the one that matters is usually not the first.
  3. For context canceled, walk up the call chain to find who cancelled: a client disconnect, a timeout, or a parent context that went out of scope are the three sources.
  4. Distinguish a nil interface from an interface holding a nil pointer. var p *T = nil; var i I = p makes i != nil, which is the cause of most "interface conversion: interface is nil" surprises.
  5. Use go tool pprof and runtime.NumGoroutine() to find goroutine leaks. A count that only ever grows means something is never returning.

Tools worth reaching for

  • go test -race
  • go vet
  • go tool pprof
  • GODEBUG=gctrace=1
  • delve (dlv)

Authoritative references

Primary documentation for this error, worth reading before applying any fix in production.

go.dev

Related Go errors

See all 19 Go errors →

Browse other categories

Something missing or wrong?

This entry is maintained by hand. If the fix is out of date, incomplete, or you have a better one, email a correction and it will be reviewed.