Fix UnrecoveredPanic: runtime error: invalid memory address or nil pointer dereference in Go

This panic occurs when code dereferences a nil pointer, and no recovery mechanism is in place to catch it. In an HTTP server, an unrecovered panic in a handler goroutine crashes only that request, but in main or background goroutines it crashes the entire process. Fix it by adding recover in background goroutines and using middleware recovery in HTTP handlers.

Reading the Stack Trace

Here's what each line means:

• main.processEvent(0x0) /app/workers/event.go:22 +0x94: The processEvent function at line 22 receives a nil pointer argument and dereferences it, causing a panic.
• runtime.gopanic({0x102840ea0, 0x1040b8900}): The Go runtime triggers a panic for the nil pointer dereference. Without a recover, this will crash the goroutine.
• created by main.(*EventWorker).Start in goroutine 1 /app/workers/event.go:12 +0x70: The goroutine was spawned by the EventWorker.Start method. Since it has no recovery, the panic is fatal.

Common Causes

func (w *EventWorker) Start() {
	go func() {
		for event := range w.events {
			processEvent(event) // panic here kills the process
		}
	}()
}

func processEvent(e *Event) {
	log.Printf("processing event: %s", e.Name) // panics if e is nil
}

func process() {
	defer cleanup() // if cleanup panics, original error is lost
	// ... work that may panic ...
}

The Fix

Wrap goroutine work in a function with defer/recover to catch panics and log them with a stack trace instead of crashing the process. Add nil checks for pointer parameters. The worker continues processing subsequent events after recovering from a panic.

func (w *EventWorker) Start() {
	go func() {
		for event := range w.events {
			processEvent(event)
		}
	}()
}

func processEvent(e *Event) {
	log.Printf("processing event: %s", e.Name)
}

func (w *EventWorker) Start() {
	go func() {
		for event := range w.events {
			w.safeProcess(event)
		}
	}()
}

func (w *EventWorker) safeProcess(event *Event) {
	defer func() {
		if r := recover(); r != nil {
			log.Printf("recovered from panic processing event: %v\n%s", r, debug.Stack())
			// optionally send to error tracking
		}
	}()
	processEvent(event)
}

func processEvent(e *Event) {
	if e == nil {
		log.Println("WARNING: received nil event, skipping")
		return
	}
	log.Printf("processing event: %s", e.Name)
}

Testing the Fix

package workers_test

import (
	"testing"

	"github.com/stretchr/testify/assert"
)

func TestProcessEvent_NilSafe(t *testing.T) {
	assert.NotPanics(t, func() {
		processEvent(nil)
	})
}

func TestProcessEvent_ValidEvent(t *testing.T) {
	assert.NotPanics(t, func() {
		processEvent(&Event{Name: "test"})
	})
}

func TestSafeProcess_RecoversPanic(t *testing.T) {
	w := &EventWorker{events: make(chan *Event, 1)}

	assert.NotPanics(t, func() {
		w.safeProcess(nil)
	})
}

func TestEventWorker_ContinuesAfterPanic(t *testing.T) {
	events := make(chan *Event, 3)
	w := &EventWorker{events: events}

	events <- nil                     // will trigger nil check
	events <- &Event{Name: "valid"}  // should process normally
	close(events)

	assert.NotPanics(t, func() {
		for event := range w.events {
			w.safeProcess(event)
		}
	})
}

Run your tests:

go test ./workers/... -v

Pushing Through CI/CD

git checkout -b fix/go-panic-recovery,git add workers/event.go workers/event_test.go,git commit -m "fix: add panic recovery and nil checks in event worker goroutine",git push origin fix/go-panic-recovery

Your CI config should look something like this:

name: CI
on:
  pull_request:
    branches: [main]
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-go@v5
        with:
          go-version: '1.22'
      - run: go mod download
      - run: go vet ./...
      - run: go test ./... -race -coverprofile=coverage.out
      - run: go build ./...

The Full Manual Process: 18 Steps

Here's every step you just went through to fix this one bug:

1. Notice the error alert or see it in your monitoring tool
2. Open the error dashboard and read the stack trace
3. Identify the file and line number from the stack trace
4. Open your IDE and navigate to the file
5. Read the surrounding code to understand context
6. Reproduce the error locally
7. Identify the root cause
8. Write the fix
9. Run the test suite locally
10. Fix any failing tests
11. Write new tests covering the edge case
12. Run the full test suite again
13. Create a new git branch
14. Commit and push your changes
15. Open a pull request
16. Wait for code review
17. Merge and deploy to production
18. Monitor production to confirm the error is resolved

Total time: 30-60 minutes. For one bug.

go get github.com/bugstack/sdk

import "github.com/bugstack/sdk"

func init() {
  bugstack.Init(os.Getenv("BUGSTACK_API_KEY"))
}

Deploying the Fix (Manual Path)

1. Run go test ./... locally to confirm panic recovery works.
2. Open a pull request with the recovery changes.
3. Wait for CI checks to pass on the PR.
4. Have a teammate review and approve the PR.
5. Merge to main and verify in staging.

Frequently Asked Questions