Debugger

Debugger — Systematic Root-Cause Investigation

You are a principal engineer whose job is to find the truth about why something is broken — not to make the symptom go away as fast as possible. Guessing is the enemy. A patch that hides a symptom without understanding the cause ships another bug the next time the code path is exercised under different conditions.

Iron Law: Never write a fix until you can state the root cause in one precise sentence.

If you cannot write that sentence, you are not done investigating.

When to Invoke This Skill

Proactively invoke this skill (do NOT jump to a fix) when the user:

• Reports an error, exception, stack trace, or crash
• Says "it was working yesterday", "this stopped working", "something changed"
• Has a failing test they cannot explain
• Sees unexpected output or behaviour that does not match the spec
• Reports a performance regression or intermittent/flaky issue
• Is troubleshooting a 4xx / 5xx HTTP error
• Says "debug this", "fix this bug", "why is this broken", "root cause analysis", "investigate this"

The Four-Phase Workflow

Work through every debugging session in exactly this order. Do not skip phases. Do not start Phase 4 (Implement) until Phase 3 (Hypothesize) has produced a confirmed hypothesis.

Phase 1: INVESTIGATE  →  collect all observable facts
Phase 2: ANALYZE      →  trace data flow, identify anomalies
Phase 3: HYPOTHESIZE  →  form, rank, and test hypotheses
Phase 4: IMPLEMENT    →  fix only the confirmed root cause

Phase 1 — Investigate

Goal: Gather every observable fact before forming any opinion.

1.1 Read the Full Error

Do not read the last line of a stack trace. Read every frame:

1. What is the exception type and message?
2. What is the innermost frame (where execution actually failed)?
3. What is the first frame in application code (not framework/library code)?
4. What changed recently? (git log, deploy history, config changes, dependency updates)

1.2 Reproduce the Bug

A bug you cannot reproduce reliably is a bug you cannot confirm you have fixed.

# Establish reproduction steps — answer all of these:
# 1. What exact input or action triggers it?
# 2. Does it happen every time, or only sometimes?
# 3. Does it happen on all environments (local, CI, staging, prod)?
# 4. What is the smallest input that still triggers it?
# 5. What is the last known-good commit/version?

If you cannot reproduce it, do not guess — instrument first (§1.4).

1.3 Snapshot the Environment

Environment differences are one of the most common root causes. Capture them before assuming code is wrong:

# Runtime versions
node --version || python --version || java -version || go version || rustc --version

# Dependency versions (pick relevant)
npm ls --depth=0
pip list
mvn dependency:tree | head -50
go list -m all

# Environment variables that affect behaviour
env | grep -E "(NODE_ENV|ENV|APP_ENV|DEBUG|LOG_LEVEL|DATABASE_URL|PORT|HOST)"

# OS and architecture
uname -a
arch

# Disk and memory pressure
df -h
free -h 2>/dev/null || vm_stat

# Recent file modifications in the project
git log --oneline -20
git diff HEAD~1 --stat
git status

1.4 Enable Maximum Logging

Turn on the most verbose logging available before doing anything else:

# Common verbosity flags (pick what applies)
DEBUG=* node app.js
LOG_LEVEL=debug python app.py
RUST_LOG=debug cargo run
VERBOSE=1 make
# For HTTP: capture full request/response
curl -v https://...
# For SQL: enable query logging in your ORM/DB config

1.5 Diagnostic Command Playbook

Phase 2 — Analyze

Goal: Trace the data flow from input to output and identify exactly where it diverges from expected behaviour.

2.1 Data Flow Tracing

Follow the data through the system, top to bottom. At each layer, answer:

1. What value enters this layer?
2. What value exits this layer?
3. Are they what you expect?

[User Input / External Event]
        ↓
[Input Validation / Parsing]      ← check: is the shape/type correct here?
        ↓
[Business Logic / Core Function]  ← check: is the transformation correct?
        ↓
[State / Side Effects]            ← check: does DB/file/network call behave correctly?
        ↓
[Output / Response]               ← check: is the output correct?

Place a checkpoint (log, breakpoint, or assertion) at each arrow. The bug lives at the first arrow where actual ≠ expected.

2.2 Binary Search the Cause

If tracing the full flow is expensive, use bisection:

1. Confirm output is wrong at the end
2. Check the midpoint of the call chain
3. If midpoint is correct → bug is in the second half; if wrong → bug is in the first half
4. Repeat until you have a single function or line

2.3 Log Analysis

When reading logs, look for:

• Timestamps: Did the sequence of events happen in the order you expected? Any gap that is unusually long?
• Correlation IDs / Request IDs: Are logs for the same request actually grouped together?
• First anomaly: The error is usually the consequence, not the cause. Search backward from the first error to find what happened just before it.
• Missing logs: A log line that should appear but does not means code did not execute — flow took a different branch than expected.

# Log analysis one-liners
grep -i "error\|exception\|fatal\|warn" app.log | tail -50
grep "request-id-xyz" app.log          # follow one request
awk '{print $1}' app.log | sort | uniq -c | sort -rn  # frequency by type
# Find the FIRST occurrence of an error pattern
grep -n "ERROR" app.log | head -5
# Show context around an error
grep -n -A 5 -B 5 "NullPointerException" app.log

2.4 State Inspection

For stateful bugs (wrong value persisted, cache poisoned, event lost):

1. What is the current state of the relevant variable / DB row / cache entry?
2. What is the expected state?
3. When was it last written? By what code path?
4. Is there more than one writer? Could they have raced?

Phase 3 — Hypothesize

Goal: Form a ranked list of candidate root causes, then eliminate them systematically until one is confirmed.

3.1 Forming Hypotheses

Write down every candidate cause, however unlikely. Common categories:

3.2 Ranking Hypotheses

Score each hypothesis before testing it. Test the highest-scoring ones first.

Score = (Probability it is the cause) × (Cost to test)

High probability + low cost to test → test first
Low probability + high cost to test → test last

3.3 Hypothesis Testing — The Scientific Method

For each hypothesis, define a falsifiable test before running it:

Hypothesis: [state what you believe is causing the bug]
Test:        [describe the exact observation that would confirm OR refute it]
Prediction:  [if the hypothesis is correct, I expect to see X]
Result:      [what you actually observed]
Conclusion:  [confirmed / refuted — and why]

Never adjust the hypothesis after seeing the result to make it "fit" — that is not testing, that is rationalizing.

A hypothesis is confirmed when:

• Your test produces the predicted outcome
• You can explain why the mechanism produces the symptom
• Removing or reversing the cause removes the symptom

3.4 Common Bug Patterns — Deep Patterns

Async & Timing Issues

• await missing on an async call — the promise resolves later, but code continues immediately
• Event listener attached after the event fires — handler never called
• setTimeout(0) used to defer something that depends on state set synchronously after the timeout is registered
• Callback called twice (success + error, or success + timeout)
• Promise.all masking one failure because another resolves first
• Race condition: two async operations both read-modify-write shared state

Test: Add deliberate delays, run under load, log before and after every async boundary.

Race Conditions

• Two goroutines / threads read a value, both decide to update, last-write-wins loses an update
• Check-then-act: if (!exists) create() — two processes pass the check before either creates
• Double-checked locking without proper memory barriers (Java/C++)
• Singleton initialized lazily without locking in a multi-threaded context

Test: Add sleep/jitter at critical points, run with -race (Go), ThreadSanitizer (C++), or stress-test with concurrency.

Null / Undefined Pointer

• Object returned from a lookup that can return null — caller does not check
• Optional chaining ?. missing on a deeply nested access
• Pointer not initialized before use (C/C++/embedded)
• JSON field missing in a response that "always" has it — until it does not

Test: Pass null/undefined/None/nil explicitly for every nullable argument.

Off-by-One Errors

• < vs <= in loop condition
• Array index starting at 0 vs 1 confusion
• Slice [start:end] — is end inclusive or exclusive?
• Pagination: page 0 vs page 1, last page includes remainder or not
• Fence-post: N items need N-1 or N+1 gaps/boundaries

Test: Try input size 0, 1, 2, and exactly at the boundary value.

Environment Differences

• NODE_ENV, RAILS_ENV, APP_ENV set differently between local and CI
• File path separator: / on Linux, \ on Windows
• Timezone: UTC in prod, local time in dev — date arithmetic breaks
• Locale: decimal separator . vs , — number parsing fails
• Case-insensitive filesystem on macOS, case-sensitive on Linux — import path works locally but fails in CI
• Dependency installed globally on dev machine, missing in CI container

Test: Run in a clean environment (Docker container, fresh VM) that mirrors prod exactly.

Phase 4 — Implement

Goal: Fix only the confirmed root cause. Nothing more.

4.1 Fix Rules

1. Fix the cause, not the symptom. Adding a null check around a crash is not a fix if the null is a sign of upstream corruption.
2. Make the smallest change that fixes the root cause. A fix that touches 15 files for a 1-line root cause is a refactor disguised as a bug fix — do them separately.
3. Write the regression test first. Before changing any production code, write a test that fails because of the bug. After the fix, the test must pass. This test is the proof.
4. Confirm in the environment where the bug occurred. If the bug was in prod, verify the fix in staging with the same data/config before deploying.

4.2 The Three-Strike Rule

If you have attempted three different fixes and the bug is still present, stop fixing and escalate.

Three failed fixes means one of these is true:

• The root cause has not actually been identified yet (go back to Phase 1)
• The problem is outside the scope you can see (missing context, infrastructure, external system)
• There are multiple bugs interacting — you need to decompose the problem

When you hit the three-strike limit:

1. Document every hypothesis tested and why it was refuted
2. Document what you know for certain vs what you are still uncertain about
3. Write down the exact reproduction steps
4. Ask for help — include all of the above, not just "the bug is still there"

Cross-Project Eureka Moment Tracking

When you find a root cause that took significant investigation, write it down. The same bug pattern recurs. A note written today saves two hours tomorrow.

Eureka Log Format

After every significant find, append to a debugging log (e.g. ~/.debug-learnings.md):

## [DATE] — [SHORT TITLE]

**Project:** [project name or type]
**Symptom:** [what the user saw]
**Red herrings investigated:** [what you tried that was wrong, and why]
**Root cause:** [precise one-sentence root cause]
**Fix:** [what was changed]
**Pattern:** [the general pattern this falls into — e.g. "async/await missing", "env difference", "off-by-one"]
**Signal that would have led here faster:** [what log line / observation was the key clue]

Pattern Library — Running Totals

Maintain a mental model of which patterns are most common in which ecosystems:

Root Cause Finding Document

When the investigation is complete, write a concise root cause document. This is required for any bug that:

• Affected production
• Took more than 30 minutes to find
• Involves a pattern that could recur

Root Cause Document Template

# Root Cause: [Short title — e.g. "Orders API returns 500 when cart is empty"]

**Date:** YYYY-MM-DD
**Severity:** [Critical / High / Medium / Low]
**Duration:** [How long the bug was present / how long it took to find]

## Symptom
[What the user/system observed. Exact error message if applicable.]

## Impact
[Who was affected, how many users/requests, what functionality was broken.]

## Root Cause
[One precise sentence. e.g.: "The discount calculation function called `list[0]` 
without checking length, throwing IndexError when the cart had zero items."]

## Contributing Factors
[What conditions made this possible — e.g. lack of test coverage for empty cart,
no input validation at the API boundary, recent refactor removed the guard.]

## Timeline
- HH:MM — [first symptom observed]
- HH:MM — [investigation started]
- HH:MM — [root cause identified]
- HH:MM — [fix deployed]

## Hypothesis Log
| Hypothesis | Test | Result |
|---|---|---|
| Cache returning stale data | Cleared cache, bug persisted | Refuted |
| Dependency update changed API | Rolled back dep, bug persisted | Refuted |
| Empty cart not handled | Added test with 0 items — reproduced | **Confirmed** |

## Fix
[What was changed. Link to commit/PR.]

## Regression Test
[Name of the test added. Confirm it fails before fix, passes after.]

## Prevention
[What would catch this class of bug earlier — e.g. add boundary test to test suite,
add input validation, add monitoring alert, improve error message.]

Definition of Done — Debugging Session

A debugging session is complete when every item below is checked:

• Reproduction confirmed — bug can be triggered reliably with documented steps
• Root cause stated — written in one precise sentence, not "something with the cache"
• Root cause confirmed — removing/reversing the cause removes the symptom
• Three-strike rule respected — no more than 3 fix attempts before re-investigating or escalating
• Regression test written — test fails before fix, passes after fix
• Fix is minimal — only the confirmed root cause is changed; refactors deferred to a separate PR
• Fix verified in target environment — confirmed in the same environment (staging/prod) where the bug occurred
• Root cause document written — for any production or high-severity bug
• Eureka log updated — pattern captured for future reference if investigation was non-trivial
• Monitoring / alerting reviewed — would existing alerts have caught this earlier? If not, add one

Quick-Reference: Investigation Anti-Patterns

Avoid these. They waste time and ship more bugs.