Golang Troubleshooting
Samuel BertheCommunityCreated by samberDistributed by Samuel Berthe
- Skill
- Review and audit
- Software development
- MIT
- Low risk
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
This skill provides a rigorous methodology for Go troubleshooting, emphasizing root cause analysis over symptom-based patching. It guides developers through a structured decision tree to identify issues ranging from compilation errors and logic bugs to complex concurrency deadlocks and memory leaks. The approach mandates reproduction before intervention, the use of diagnostic tools like Delve and pprof, and adherence to Go-specific best practices to ensure fixes are durable and do not introduce regressions.
What it does
- Provides a decision tree to categorize symptoms like crashes, hangs, or unexpected logic.
- Defines a strict debugging methodology: read errors, reproduce, isolate, and verify.
- Outlines common Go pitfalls including nil pointers, interface gotchas, and concurrency bugs.
- Instructs on the use of diagnostic tools such as pprof, Delve, and the race detector.
- Supports both single-issue debugging and large-scale codebase bug hunts.
- Enforces evidence-based reasoning to prevent guessing and superficial fixes.
When to use it
- When encountering unexpected behavior, crashes, or panics in Go code.
- When diagnosing performance bottlenecks, high CPU usage, or memory growth.
- When investigating flaky tests or intermittent concurrency issues like deadlocks.
- When you need to perform a systematic audit of a large codebase for potential bugs.
- When you are stuck on a bug and need a structured approach to isolate the root cause.
Advantages
- Reduces time wasted on trial-and-error fixes.
- Ensures long-term stability by addressing root causes rather than symptoms.
- Provides a clear, repeatable process for complex production issues.
- Leverages standard Go tooling for accurate diagnostics.
- Helps avoid common Go-specific anti-patterns and pitfalls.
Usage examples
- “My Go application is hanging intermittently. How do I find the cause?”
- The agent will guide you to use pprof to capture a goroutine dump and analyze it for deadlocks or blocked channels.
- “I have a random panic in my production service. Where do I start?”
- The agent will help you analyze the stack trace, check for common nil pointer dereferences, and suggest reproduction steps.
- “How can I find race conditions in my concurrent Go code?”
- The agent will instruct you to run your tests with the -race flag and interpret the output to locate the conflicting memory access.
- “I suspect a memory leak in my service. What should I do?”
- The agent will walk you through capturing heap profiles with pprof and comparing them to identify growing allocations.
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/samber/golang-troubleshooting/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip golang-troubleshooting.zip -d .agents/skills
Documentation by samber
Persona: You are a Go systems debugger. You follow evidence, not intuition — instrument, reproduce, and trace root causes systematically.
Thinking mode: Reason as thoroughly as possible for debugging and root cause analysis — rushed reasoning leads to symptom fixes, deep thinking finds the actual root cause. On Claude Code, use ultrathink to trigger extended thinking explicitly.
Orchestration mode: Fan out the five bug-category sub-agents described in Codebase bug hunt mode for a codebase-wide bug hunt. A single-issue debug session should stay sequential; orchestration only pays off when scanning broadly for unknown bugs. On Claude Code, use ultracode to opt into multi-agent orchestration explicitly.
Modes:
Single-issue debug (default): Follow the sequential Golden Rules — read the error, reproduce, one hypothesis at a time. Do not launch sub-agents; focused sequential investigation is faster for a single known symptom.
Codebase bug hunt (explicit audit of a large codebase): Launch up to 5 parallel sub-agents, one per bug category (nil/interface, resources, error handling, races, context/slice/map). Use this mode when the user asks for a broad sweep, not when debugging a specific reported issue.
Dependencies:
dlv:
go install github.com/go-delve/delve/cmd/dlv@latest
Go Troubleshooting Guide
NO FIXES WITHOUT ROOT CAUSE INVESTIGATION FIRST. Symptom fixes create new bugs and waste time. This process applies ESPECIALLY under time pressure — rushing leads to cascading failures that take longer to resolve.
When the user reports a bug, crash, performance problem, or unexpected behavior in Go code:
Start with the Decision Tree below to identify the symptom category and jump to the relevant section.
Follow the Golden Rules — especially: reproduce before you fix, one hypothesis at a time, find the root cause.
Work through the General Debugging Methodology step by step. Do not skip steps.
Watch for Red Flags in your own reasoning. If you catch yourself guessing at fixes without understanding the cause, stop and gather more evidence.
Escalate tools incrementally. Start with the simplest diagnostic (
fmt.Println, test isolation) and only reach for pprof, Delve, or GODEBUG when simpler tools are insufficient.Never propose a fix you cannot explain. If you do not understand why the bug happens, say so and investigate further.
Quick Decision Tree
WHAT ARE YOU SEEING?
"Build won't compile"
→ go build ./... 2>&1, go vet ./...
→ See [compilation.md](./references/compilation.md)
"Wrong output / logic bug"
→ Write a failing test → Check error handling, nil, off-by-one
→ See [common-go-bugs.md](./references/common-go-bugs.md), [testing-debug.md](./references/testing-debug.md)
"Random crashes / panics"
→ GOTRACEBACK=all ./app → go test -race ./...
→ See [common-go-bugs.md](./references/common-go-bugs.md), [diagnostic-tools.md](./references/diagnostic-tools.md)
"Sometimes works, sometimes fails"
→ go test -race ./...
→ See [concurrency-debug.md](./references/concurrency-debug.md), [testing-debug.md](./references/testing-debug.md)
"Program hangs / frozen"
→ curl localhost:6060/debug/pprof/goroutine?debug=2
→ See [concurrency-debug.md](./references/concurrency-debug.md), [pprof.md](./references/pprof.md)
"High CPU usage"
→ pprof CPU profiling
→ See [performance-debug.md](./references/performance-debug.md), [pprof.md](./references/pprof.md)
"Memory growing over time"
→ pprof heap profiling
→ See [performance-debug.md](./references/performance-debug.md), [concurrency-debug.md](./references/concurrency-debug.md)
"Slow / high latency / p99 spikes"
→ CPU + mutex + block profiles
→ See [performance-debug.md](./references/performance-debug.md), [diagnostic-tools.md](./references/diagnostic-tools.md)
"Simple bug, easy to reproduce"
→ Write a test, add fmt.Println / log.Debug
→ See [testing-debug.md](./references/testing-debug.md)Remember: Read the Error → Reproduce → Measure One Thing → Fix → Verify
Most Go bugs are: missing error checks, nil pointers, forgotten context cancel, unclosed resources, race conditions, or silent error swallowing.
The Golden Rules
1. Read the Error Message First
Go error messages are precise. Read them fully before doing anything else:
File and line number → go directly there
Type mismatch → check function signatures, interface satisfaction
"undefined" → check imports, exported names, build tags
"cannot use X as Y" → check concrete types vs interfaces
2. Reproduce Before You Fix
NEVER debug by guessing — reproduce first. Always:
Write a failing test that captures the bug
Make it deterministic
Isolate the minimal failing example
Use
git bisectto find the breaking commit
3. If You Don't Measure It, You're Guessing
Never rely on intuition for performance or concurrency bugs:
pprof over intuition
race detector over reasoning
benchmarks over assumptions
4. One Hypothesis at a Time
Change one thing, measure, confirm. If you change three things at once, you learn nothing.
5. Find the Root Cause — No Workarounds
You MUST understand why the bug happens before writing a fix. A band-aid that masks the symptom leaves the defect in place, so it resurfaces elsewhere — usually further from its cause and harder to trace the second time.
When you don't understand the issue:
Trace the data flow backwards from the symptom to its origin.
Question your assumptions. The code you trust might be wrong.
Ask "why" five times. Keep going until you reach the actual root cause.
Perform more troubleshooting checks. More fmt.Println, more output inspection...
6. Research the Codebase, Not Just the Diff
Before flagging a bug or proposing a fix, trace the data flow and check for upstream handling. A function that looks broken in isolation may be correct in context — callers may validate inputs, middleware may enforce invariants, or the surrounding code may guarantee conditions the function relies on.
Trace callers — who calls this function and with what values? Call sites can be found with code search tools. → See
samber/cc-skills-golang@golang-goplsskill to resolve the actual symbol through interfaces and embedding — it finds indirect call sites and skips unrelated same-named identifiers that plain grep would respectively miss or falsely match.Check upstream validation — input parsing, type conversions, or guard clauses earlier in the chain may make the "bug" unreachable.
Read the surrounding code — middleware, interceptors, or init functions may set up state the function depends on.
When the context reduces severity but doesn't eliminate the issue: still report it at reduced priority with a note explaining which upstream guarantees protect it. Add a brief inline comment (e.g., // note: safe because caller validates via parseID() which returns uint) so the reasoning is documented for future reviewers.
7. Start Simple
Sometimes fmt.Println IS the right tool for local debugging. Escalate tools only when simpler approaches fail. NEVER use fmt.Println for production debugging — use slog.
Red Flags: You're Debugging Wrong
If any of these are happening, stop and return to Step 1:
"Quick fix for now, investigate later" — There is no "later". Find the root cause.
Multiple simultaneous changes — One hypothesis at a time.
Proposing fixes without understanding the cause — "Maybe if I add a nil check here..." is guessing, not debugging.
Each fix reveals a new problem — You're treating symptoms. The real bug is elsewhere.
3+ fix attempts on the same issue — You have the wrong mental model. Re-read the code, trace the data flow from scratch.
"It works on my machine" — You haven't isolated the environmental difference.
Blaming the framework/stdlib/compiler — It's almost never a Go bug. Verify your code first.
Reference Files
General Debugging Methodology — The systematic 10-step process: define symptoms, isolate reproduction, form one hypothesis, test it, verify the root cause, and defend against regressions. Escalation guide: when to escalate from
fmt.Printlnto logging to pprof to Delve, and how to avoid the trap of multiple simultaneous changes.Common Go Bugs — The bugs that crash Go code: nil pointer dereferences, interface nil gotcha (typed nil ≠ nil), variable shadowing, slice/map/defer/error/context pitfalls, race conditions, JSON unmarshaling surprises, unclosed resources. Each with reproduction patterns and fixes.
Test-Driven Debugging — Why writing a failing test is the first step of debugging. Covers test isolation techniques, table-driven test organization for narrowing failures, useful
go testflags (-v,-run,-count=10for flaky tests), and debugging flaky tests.Concurrency Debugging — Race conditions, deadlocks, goroutine leaks. When to use the race detector (
-race), how to read race detector output, patterns that hide races, detecting leaks withgoleak, analyzing stack dumps for deadlock clues.Performance Troubleshooting — When your code is slow: CPU profiling workflow, memory analysis (heap vs alloc_objects profiles, finding leaks), lock contention (mutex profile), and I/O blocking (goroutine profile). How to read flamegraphs, identify hot functions, and measure improvement with benchmarks.
pprof Reference — Complete pprof manual. How to enable pprof endpoints in production (with auth), profile types (CPU, heap, goroutine, mutex, block, trace), capturing profiles locally and remotely, interactive analysis commands (
top,list,web), and interpreting flamegraphs.Diagnostic Tools — Auxiliary tools for specific symptoms. GODEBUG environment variables (GC tracing, scheduler tracing), Delve debugger for breakpoint debugging, escape analysis (
go build -gcflags="-m"to find unintended heap allocations), Go's execution tracer for understanding goroutine scheduling.Production Debugging — Debugging live production systems without stopping them. Production checklist, structuring logs for searchability, enabling pprof safely (auth, network isolation), capturing profiles from running services, network debugging (tcpdump, netstat), and HTTP request/response inspection.
Compilation Issues — Build failures: module version conflicts, CGO linking problems, version mismatch between
go.modand installed Go version, platform-specific build tags preventing cross-compilation.Code Review Red Flags — Patterns to watch during code review that signal potential bugs: unchecked errors, missing nil checks, concurrent map access, goroutines without clear exit, resource leaks from defer in loops.
Cross-References
→ See
samber/cc-skills-golang@golang-performanceskill for optimization patterns after identifying bottlenecks→ See
samber/cc-skills-golang@golang-observabilityskill for metrics, alerting, and Grafana dashboards for Go runtime monitoring→ See
samber/cc-skills@promql-cliskill for querying Prometheus metrics during production incident investigation→ See
samber/cc-skills-golang@golang-concurrency,samber/cc-skills-golang@golang-safety,samber/cc-skills-golang@golang-error-handlingskills
Files
- ATTRIBUTION.mdAdded by AutoGineer923 B
- LICENSELicence file added by AutoGineer1.0 KiB
- SKILL.md13.0 KiB
- evals/evals.json45.0 KiB
- references/code-review-flags.md1.9 KiB
- references/common-go-bugs.md25.4 KiB
- references/compilation.md647 B
- references/concurrency-debug.md3.0 KiB
- references/diagnostic-tools.md3.6 KiB
- references/methodology.md10.0 KiB
- references/performance-debug.md1.5 KiB
- references/pprof.md5.1 KiB
- references/production-debug.md3.7 KiB
- references/testing-debug.md3.2 KiB
references/common-go-bugs.md
Common Go Bugs
→ See samber/cc-skills-golang@golang-safety skill for in-depth nil, slice, and map safety patterns.
Table of Contents
Nil Pointer Dereference
Interface Nil Gotcha
Variable Shadowing with
:=Slice and Map Gotchas
Defer Gotchas
Error Handling Pitfalls
Context Misuse
Concurrent Map Read/Write (Fatal)
Copying sync Types
WaitGroup.Add Inside Goroutine
Missing Return After HTTP Error Response
JSON Pitfalls
Numbers into
interface{}becomefloat64Unexported fields silently ignored
strings.Trimvsstrings.TrimPrefixString Length and Indexing
breakinselect/switchInsideforLoopEnum Zero Value with
iotarecover()Only Works in the Same Goroutineos.ExitSkips Deferred Functionstime.TimeComparison:==vs.Equal()sql.RowsMust Be ClosedWriting to a Closed Channel Panics
Closed Channel in
selectCauses Busy LoopselectwithdefaultCan Spin CPUInteger Conversion Silently Truncates
filepath.JoinDoes Not Prevent Path TraversalPointer Receiver Interface Satisfaction
regexp.MustCompilein Hot Pathinit()Ordering Is FragileMap Iteration Order Is Random
fallthroughinswitchExecutes Unconditionally
Nil Pointer Dereference
Pointers from external sources MUST be checked before dereferencing.
The most common Go panic. The stack trace tells you the exact line.
// 1. Uninitialized struct field
type Server struct {
logger *log.Logger // nil if not set in constructor
}
// 2. Unchecked error return — if err != nil, val may be nil/zero
val, err := doSomething()
val.Method() // panic if doSomething returned nil val with an error
// 3. Map lookup returns zero value
m := map[string]*Config{}
cfg := m["missing"] // cfg is nil
cfg.Timeout // panic
// 4. Type assertion without comma-ok
var i interface{} = "hello"
n := i.(int) // panic
n, ok := i.(int) // ok == false, no panicInterface Nil Gotcha
NEVER compare an interface to nil when it may contain a typed nil pointer.
A typed nil pointer inside an interface is not a nil interface:
type MyError struct{ msg string }
func (e *MyError) Error() string { return e.msg }
func doWork() error {
var err *MyError // typed nil pointer
return err // returns non-nil interface containing nil pointer!
}
func main() {
if err := doWork(); err != nil {
// This EXECUTES — the interface is non-nil
fmt.Println(err) // panic: nil pointer in Error()
}
}
// FIX: return nil explicitly, not a typed nil variable
func doWork() error {
return nil
}Variable Shadowing with :=
The := short declaration creates a new variable in the inner scope instead of assigning to the outer one. Especially dangerous when shadowing err, because error handling silently breaks.
// BAD
func doWork() error {
var err error
if condition {
result, err := someFunc() // BUG: new err variable, doesn't set outer one
if err != nil {
return err
}
process(result)
}
return err // always nil — inner err was a different variable
}
// GOOD
func doWork() error {
var err error
if condition {
var result ResultType
result, err = someFunc() // assigns to outer err
if err != nil {
return err
}
process(result)
}
return err
}Detect: run the golang.org/x/tools/go/analysis/passes/shadow analyzer through your lint setup. The old shadow flag is not part of standard go vet.
Slice and Map Gotchas
// 1. Nil map write panics
var m map[string]int
m["key"] = 1 // panic: assignment to entry in nil map
// FIX: m := make(map[string]int)
// Note: nil map reads are fine — they return zero value
// 2. Append may share underlying array
a := []int{1, 2, 3}
b := a[:2]
b = append(b, 99) // overwrites a[2]!
// FIX: full slice expression — b := a[:2:2] to limit capacity
// 3. Range variable capture in goroutine (Go < 1.22)
for _, v := range items {
go func() {
process(v) // v is shared, will likely be last element
}()
}
// FIX: pass as argument
for _, v := range items {
go func(v Item) { process(v) }(v)
}
// In Go 1.22+, loop variables are per-iteration (no fix needed)Defer Gotchas
// 1. Arguments evaluated immediately
x := 1
defer fmt.Println(x) // prints 1, not 2
x = 2
// 2. Defer in loop — doesn't run until function returns
for _, f := range files {
file, _ := os.Open(f)
defer file.Close() // all Close() calls pile up until return
}
// FIX: wrap in closure
for _, f := range files {
func() {
file, _ := os.Open(f)
defer file.Close()
// use file
}()
}
// 3. Named return + defer interaction
func readFile() (err error) {
f, err := os.Open("file.txt")
if err != nil { return }
defer func() {
if closeErr := f.Close(); err == nil {
err = closeErr // modifies named return
}
}()
// ...
return nil
}Error Handling Pitfalls
Silent error swallowing is the single most common source of "mysterious" bugs:
// BAD — silent failure
result, _ := doSomething()
json.Unmarshal(data, &config)
http.ListenAndServe(":8080", nil)
// GOOD — handle or propagate
result, err := doSomething()
if err != nil {
return fmt.Errorf("doSomething: %w", err)
}Find ignored errors:
go vet ./...
# More thorough
go get -tool github.com/kisielk/errcheck@latest
go tool errcheck ./...Error wrapping — use %w, not %v:
return fmt.Errorf("reading config from %s: %v", path, err) // BAD — loses error chain
return fmt.Errorf("reading config from %s: %w", path, err) // GOOD — preserves Is/As
// Check for specific errors — use errors.Is, not ==
if err == sql.ErrNoRows { ... } // BAD — breaks if wrapped
if errors.Is(err, sql.ErrNoRows) { ... } // GOOD — traverses chain
// Extract typed errors
var pathErr *os.PathError
if errors.As(err, &pathErr) { ... }Context Misuse
// 1. Forgetting to cancel — leaks goroutines
ctx, cancel := context.WithTimeout(ctx, 5*time.Second)
// Missing: defer cancel()
// 2. Using background context when you should propagate
go doWork(context.Background()) // BAD — can't cancel from parent
go doWork(ctx) // GOOD — respects parent cancellation
// 3. Not checking context error
err := doWork(ctx)
if err != nil {
// Distinguish timeout from other errors
if ctx.Err() == context.DeadlineExceeded {
log.Printf("operation timed out")
} else if ctx.Err() == context.Canceled {
log.Printf("operation cancelled")
} else {
log.Printf("operation failed: %v", err)
}
}
// 4. Background work outliving request context
func handler(w http.ResponseWriter, r *http.Request) {
// BAD — background work uses request context that cancels when client disconnects
go processAsync(r.Context(), data)
// GOOD — derive a new context for background work (Go 1.21+)
bgCtx := context.WithoutCancel(r.Context())
go processAsync(bgCtx, data)
}Concurrent Map Read/Write (Fatal)
Maps MUST NOT be accessed concurrently without synchronization.
Unlike most Go runtime errors, a concurrent map read/write is a fatal error — it cannot be caught with recover() and crashes the entire process. Hard to catch in tests because it depends on timing.
// BAD — fatal: concurrent map read and map write
m := make(map[string]int)
go func() { m["key"] = 1 }() // concurrent write
go func() { _ = m["key"] }() // concurrent read — fatal!
// GOOD — protect with mutex
var mu sync.RWMutex
m := make(map[string]int)
go func() { mu.Lock(); m["key"] = 1; mu.Unlock() }()
go func() { mu.RLock(); _ = m["key"]; mu.RUnlock() }()
// Or use sync.Map for read-heavy workloads with stable key setsDetect: go test -race ./... — always run in CI.
Copying sync Types
Sync types MUST NEVER be copied — use pointer receivers and pass by pointer.
All sync types (Mutex, RWMutex, WaitGroup, Once, Cond, Map, Pool) must not be copied. Copying them via value receivers, function arguments, or struct assignment silently breaks synchronization.
// BAD — value receiver copies the Mutex
type Counter struct {
mu sync.Mutex
count int
}
func (c Counter) Increment() { // BUG: copies mutex on every call
c.mu.Lock()
c.count++
c.mu.Unlock()
}
// GOOD — pointer receiver
func (c *Counter) Increment() {
c.mu.Lock()
defer c.mu.Unlock()
c.count++
}Detect: go vet detects mutex copies. Apply to all sync types.
WaitGroup.Add Inside Goroutine
If wg.Add(1) is called inside the goroutine instead of before it, wg.Wait() may return before all goroutines start — a race condition that passes tests most of the time but fails intermittently.
// BAD
var wg sync.WaitGroup
for i := 0; i < n; i++ {
go func() {
wg.Add(1) // BUG: may run after wg.Wait() returns
defer wg.Done()
doWork()
}()
}
wg.Wait()
// GOOD
var wg sync.WaitGroup
for i := 0; i < n; i++ {
wg.Add(1) // called BEFORE launching the goroutine
go func() {
defer wg.Done()
doWork()
}()
}
wg.Wait()Missing Return After HTTP Error Response
After writing an error with http.Error(), execution continues. This can cause double writes, corrupted responses, or executing logic that should have been skipped.
// BAD
func handler(w http.ResponseWriter, r *http.Request) {
if !authorized(r) {
http.Error(w, "Forbidden", http.StatusForbidden)
// BUG: missing return — handler keeps executing
}
doSensitiveAction(r)
}
// GOOD
func handler(w http.ResponseWriter, r *http.Request) {
if !authorized(r) {
http.Error(w, "Forbidden", http.StatusForbidden)
return
}
doSensitiveAction(r)
}JSON Pitfalls
Numbers into interface{} become float64
When unmarshaling into map[string]interface{} or interface{}, all JSON numbers become float64. Type-asserting to int panics. Large integers (> 2^53) silently lose precision.
// BAD
var result map[string]interface{}
json.Unmarshal([]byte(`{"id": 1234567890123456789}`), &result)
id := result["id"].(int) // PANIC: it's float64, not int
// GOOD — use typed struct (preferred)
type Response struct {
ID int64 `json:"id"`
}
// GOOD — use json.Number when you must use interface{}
dec := json.NewDecoder(bytes.NewReader(data))
dec.UseNumber()
var result map[string]interface{}
dec.Decode(&result)
id, _ := result["id"].(json.Number).Int64()Unexported fields silently ignored
Fields starting with lowercase are invisible to encoding/json. Marshal produces empty output, unmarshal skips them — no error in either case.
// BAD
type User struct {
name string `json:"name"` // unexported — silently ignored!
email string `json:"email"` // unexported — silently ignored!
}
u := User{name: "Alice", email: "[email protected]"}
data, _ := json.Marshal(u) // data is "{}" — no error
// GOOD
type User struct {
Name string `json:"name"`
Email string `json:"email"`
}Detect: go vet warns when unexported fields have JSON struct tags.
strings.Trim vs strings.TrimPrefix
strings.Trim treats its second argument as a set of characters to strip from both ends, not as a substring. This over-trims unexpectedly.
// BAD
s := strings.Trim("application/json", "application/")
// Result: "js" — stripped all chars in set {a,p,l,i,c,t,o,n,/} from both ends!
// GOOD
s := strings.TrimPrefix("application/json", "application/")
// Result: "json"Use strings.TrimPrefix/strings.TrimSuffix to remove substrings. Only use strings.Trim when you intend to strip a set of characters.
String Length and Indexing
len() on strings returns bytes, not characters. Indexing returns a byte. For multi-byte UTF-8 characters, this gives wrong counts and corrupts data when slicing.
s := "Hello, 世界"
fmt.Println(len(s)) // 13 (bytes), not 9 (characters)
fmt.Println(s[:8]) // "Hello, \xe4" — corrupted! cuts a multi-byte rune
// FIX: use utf8.RuneCountInString for character count
fmt.Println(utf8.RuneCountInString(s)) // 9
// FIX: convert to []rune for character-based slicing
runes := []rune(s)
fmt.Println(string(runes[:8])) // "Hello, 世"
// FIX: use for-range to iterate over characters (runes), not bytes
for _, r := range s { ... } // iterates runesbreak in select/switch Inside for Loop
A bare break inside a select or switch that is inside a for loop only exits the select/switch, not the loop.
// BAD
for {
select {
case msg := <-ch:
if msg == "quit" {
break // BUG: only breaks the select, loop continues forever
}
process(msg)
}
}
// GOOD — use labeled break
loop:
for {
select {
case msg := <-ch:
if msg == "quit" {
break loop // breaks the for loop
}
process(msg)
}
}Enum Zero Value with iota
When iota starts at 0, the zero value of the type (from uninitialized variables, zero-value struct fields, or missing JSON fields) is indistinguishable from the first constant.
// BAD
type Status int
const (
Active Status = iota // 0 — same as zero value!
Inactive // 1
)
type User struct {
Status Status // zero value is Active — but was it intentional?
}
// GOOD — reserve 0 for "unknown"
type Status int
const (
StatusUnknown Status = iota // 0 — explicit unset sentinel
StatusActive // 1
StatusInactive // 2
)recover() Only Works in the Same Goroutine
recover() can only catch panics in the goroutine where it's deferred. A panic in a child goroutine will crash the entire program — no parent goroutine can catch it.
// BAD — recover() in main cannot catch panic in child goroutine
func main() {
defer func() {
if r := recover(); r != nil {
fmt.Println("recovered:", r) // NEVER REACHED
}
}()
go func() {
panic("crash!") // crashes the whole program
}()
time.Sleep(time.Second)
}
// GOOD — each goroutine must recover its own panics
func main() {
go func() {
defer func() {
if r := recover(); r != nil {
log.Printf("goroutine recovered: %v", r)
}
}()
panic("crash!") // recovered within this goroutine
}()
time.Sleep(time.Second)
}os.Exit Skips Deferred Functions
os.Exit terminates the process immediately. No deferred functions run — cleanup, flush, and close operations are skipped. log.Fatal calls os.Exit(1) internally and has the same problem.
// BAD — deferred cleanup never runs
func main() {
f, _ := os.Create("data.tmp")
defer f.Close() // NEVER RUNS
defer os.Remove(f.Name()) // NEVER RUNS
if err := process(); err != nil {
log.Fatal(err) // calls os.Exit(1) — skips all defers!
}
}
// GOOD — return from main instead, or restructure so defers run
func main() {
if err := run(); err != nil {
fmt.Fprintf(os.Stderr, "error: %v\n", err)
os.Exit(1) // defers in run() already ran when it returned
}
}
func run() error {
f, _ := os.Create("data.tmp")
defer f.Close()
return process()
}time.Time Comparison: == vs .Equal()
time.Time includes a monotonic clock reading. Two time.Time values representing the same instant may not be == if one has a monotonic component and the other doesn't (e.g., one from time.Now(), the other deserialized from JSON/database).
// BAD — may fail even for the same instant
t1 := time.Now()
data, _ := t1.MarshalJSON()
var t2 time.Time
t2.UnmarshalJSON(data)
fmt.Println(t1 == t2) // false! t1 has monotonic, t2 doesn't
// GOOD — .Equal() ignores monotonic clock
fmt.Println(t1.Equal(t2)) // true
// Also: strip monotonic explicitly when storing/comparing
t1 = t1.Round(0) // strips monotonic readingsql.Rows Must Be Closed
sql.Rows MUST call rows.Close() — always defer it immediately after the query.
Forgetting to close sql.Rows leaks database connections. The connection is held until Rows is garbage collected, but under load the connection pool exhausts first.
// BAD — connection leak if rows aren't closed
rows, err := db.Query("SELECT id FROM users")
if err != nil { return err }
for rows.Next() {
// ...
}
// rows never closed — connection leak!
// GOOD — always defer Close
rows, err := db.Query("SELECT id FROM users")
if err != nil { return err }
defer rows.Close()
for rows.Next() {
// ...
}
if err := rows.Err(); err != nil { // don't forget to check rows.Err()
return err
}Also: use db.QueryRow() for single-row queries and db.Exec() for non-SELECT statements (INSERT, UPDATE, DELETE). Using db.Query() for non-SELECT leaks connections because the returned Rows is never iterated/closed.
Writing to a Closed Channel Panics
Sending to a closed channel panics. Reading from a closed channel returns the zero value immediately (with ok == false).
// BAD — panic: send on closed channel
ch := make(chan int, 1)
close(ch)
ch <- 1 // panic!
// GOOD — only the sender should close, never the receiver
// Use a done channel or context to signal completion
func producer(ch chan<- int, done <-chan struct{}) {
defer close(ch)
for i := 0; ; i++ {
select {
case ch <- i:
case <-done:
return
}
}
}Rule of thumb: Only the sender closes the channel. If multiple senders, use a sync.Once or coordinate with a sync.WaitGroup.
Closed Channel in select Causes Busy Loop
A closed channel is always ready to receive (returns zero value). In a select, this causes the case to fire continuously — a CPU-burning busy loop.
// BAD — after ch is closed, this loops at 100% CPU
for {
select {
case v := <-ch: // fires continuously after ch closes
process(v) // processes zero values forever
case <-done:
return
}
}
// GOOD — nil the channel after it closes
for {
select {
case v, ok := <-ch:
if !ok {
ch = nil // nil channel blocks forever in select — disables this case
continue
}
process(v)
case <-done:
return
}
}select with default Can Spin CPU
A select with a default case never blocks. Inside a for loop, this creates a busy-wait spin loop that burns CPU.
// BAD — spins at 100% CPU waiting for a message
for {
select {
case msg := <-ch:
process(msg)
default:
// runs immediately when ch has nothing — tight loop!
}
}
// GOOD — remove default to block until a message arrives
for {
select {
case msg := <-ch:
process(msg)
case <-ctx.Done():
return
}
}
// GOOD — if you need non-blocking check, add a small sleep or ticker
for {
select {
case msg := <-ch:
process(msg)
default:
time.Sleep(10 * time.Millisecond) // yield CPU
}
}Integer Conversion Silently Truncates
Go integer conversions don't check for overflow — they silently truncate. This is especially dangerous when converting from user input or external data.
// BAD — silent truncation
var big int64 = 256
small := int8(big)
fmt.Println(small) // 0 — silently overflowed!
var n int64 = math.MaxInt64
n32 := int32(n)
fmt.Println(n32) // -1 — silently wrapped!
// GOOD — check bounds before converting
func safeIntToInt32(n int64) (int32, error) {
if n < math.MinInt32 || n > math.MaxInt32 {
return 0, fmt.Errorf("value %d overflows int32", n)
}
return int32(n), nil
}filepath.Join Does Not Prevent Path Traversal
filepath.Join cleans the path (resolves ..) but doesn't prevent escaping the base directory. User-supplied paths can traverse outside the intended root.
// BAD — user can escape the base directory
base := "/srv/files"
userInput := "../../etc/passwd"
path := filepath.Join(base, userInput)
// path = "/etc/passwd" — escaped!
// GOOD (Go 1.24+) — confine access to the base directory
root, err := os.OpenRoot("/srv/files")
if err != nil {
return err
}
defer root.Close()
file, err := root.Open(userInput)
if err != nil {
return err
}
defer file.Close()For Go <1.24, use a lexical fallback only when os.Root is unavailable:
func safePath(base, userInput string) (string, error) {
if userInput == "" || filepath.IsAbs(userInput) || !filepath.IsLocal(userInput) {
return "", fmt.Errorf("invalid relative path: %q", userInput)
}
path := filepath.Join(base, userInput)
rel, err := filepath.Rel(base, path)
if err != nil {
return "", fmt.Errorf("checking path: %w", err)
}
if rel == ".." || strings.HasPrefix(rel, ".."+string(os.PathSeparator)) {
return "", fmt.Errorf("path traversal attempt: %s", userInput)
}
return path, nil
}Pointer Receiver Interface Satisfaction
A value of type T cannot satisfy an interface that requires methods with *T receivers. But *T satisfies interfaces requiring either T or *T methods.
type Sizer interface {
Size() int
}
type File struct{ size int }
func (f *File) Size() int { return f.size } // pointer receiver
var s Sizer
s = File{} // COMPILE ERROR: File does not implement Sizer (*File does)
s = &File{} // OK — *File has the Size method
// This is because the compiler can't always take the address of a value
// (e.g., map values, return values). Pointer receiver = pointer required.regexp.MustCompile in Hot Path
Long-lived regexp MUST be compiled once at package level — not inside functions called repeatedly. Short-lived regexp used once (e.g., in a CLI or test) are acceptable inline.
regexp.MustCompile compiles a regex every call. In a hot path (loop, HTTP handler), this is expensive and wasteful.
// BAD — recompiles regex on every call
func isEmail(s string) bool {
re := regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
return re.MatchString(s)
}
// GOOD — compile once at package level
var emailRe = regexp.MustCompile(`^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}$`)
func isEmail(s string) bool {
return emailRe.MatchString(s)
}init() Ordering Is Fragile
init() functions run in source file order within a package, and in dependency order across packages. But relying on this order creates brittle, hard-to-debug initialization sequences. Multiple init() in the same file run top-to-bottom, but across files it's alphabetical by filename — adding a file can change the order.
// BAD — init() depends on another init() having run first
var db *sql.DB
func init() {
// Assumes config init() already ran — fragile!
db, _ = sql.Open("postgres", config.DatabaseURL)
}
// GOOD — use explicit initialization
func main() {
cfg := loadConfig()
db := setupDatabase(cfg)
startServer(db)
}Prefer explicit initialization in main() over init(). Use init() only for truly self-contained setup (registering drivers, codecs).
Map Iteration Order Is Random
Go deliberately randomizes map iteration order. Code that assumes a specific order will produce inconsistent results.
// BAD — output order is random every run
m := map[string]int{"a": 1, "b": 2, "c": 3}
for k, v := range m {
fmt.Printf("%s=%d ", k, v) // different order each time!
}
// GOOD — sort keys when order matters
keys := make([]string, 0, len(m))
for k := range m {
keys = append(keys, k)
}
sort.Strings(keys)
for _, k := range keys {
fmt.Printf("%s=%d ", k, m[k])
}This is especially dangerous in tests (non-deterministic output comparison), serialization (non-deterministic JSON/output), and logging (confusing diffs).
fallthrough in switch Executes Unconditionally
Unlike C, Go's switch cases don't fall through by default. But when you explicitly use fallthrough, it executes the next case body unconditionally — it does not check the next case's condition.
// Surprising: fallthrough doesn't check the next condition
switch x := 5; {
case x > 10:
fmt.Println(">10")
fallthrough
case x > 0:
fmt.Println(">0")
fallthrough
case x < 0:
fmt.Println("<0") // EXECUTES even though 5 is not < 0!
}
// Output: >0, <0
// fallthrough is rarely needed. Prefer listing multiple values:
switch status {
case "active", "enabled":
enable()
}Requirements and compatibility
Written for: Claude Code, OpenAI Codex
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Declares allowed tools, Claude Code frontmatter
The author says: Designed for Claude Code, Codex or similar harness, and for projects using Golang.
Security
What our scanner noticed· Low risk
- Instructions that use the network
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Created by
- samber
- Publisher
- Samuel Berthe (Community)
- Distributed by
- Samuel Berthe
- Source
- samber/cc-skills-golang · skills/golang-troubleshooting · commit bb1d43d
- Licence
- MIT License (redistribution allowed)
- LICENSE (added by AutoGineer from LICENSE)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by samber or Samuel Berthe.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download golang-troubleshooting.zip