Debugging Study Guide

📖 Core Concepts Debugging – locating the root cause of a defect, finding work‑arounds, and identifying possible fixes. Debugger – a software tool that lets you monitor execution, pause/restart, set breakpoints, and modify memory. Tactics – interactive stepping, control‑flow analysis, log‑file inspection, performance profiling, memory‑dump analysis, remote debugging, record‑and‑replay, time‑travel, delta debugging, bisect (Wolf Fence). Static Code Analysis – examines source for known semantic problems (e.g., use‑before‑assignment) without running the program; complements the compiler’s syntax checks. False Positive – a warning that flags correct code as a problem (classic example: Unix lint). Heisenbug – a defect that changes or disappears when you try to observe it (e.g., under a debugger). Anti‑Debugging – techniques embedded in code to detect or hinder debuggers (used by copy‑protection or malware). --- 📌 Must Remember Reproduce first – you must have a reliable set of steps that trigger the bug. Simplify the test case – reduce inputs/code to the smallest version that still fails (divide‑and‑conquer). Breakpoints & Watchpoints – pause execution at a line or when a variable changes. Bisect (Wolf Fence) – repeatedly halve the change set to pinpoint the commit that introduced the bug. Post‑mortem – use core dumps, stack traces, and logs after a crash. Delta debugging – automated removal of input parts to find the minimal failure‑inducing subset. Static analysis ≠ guarantee – it can miss bugs and produce false positives. Heisenbug symptom – bug vanishes when you add instrumentation (print statements, breakpoints). Anti‑debugging signals – API checks, exception handling, process/thread structure checks, modified code detection, hardware breakpoint detection, timing/latency checks. --- 🔄 Key Processes Standard Debugging Workflow Identify reproducible steps. Simplify the test case (remove unrelated code, shrink input). Reduce GUI interactions if possible. Open a debugger → set breakpoints / watchpoints. Inspect variable values & call stack to trace the origin. Confirm fix and re‑run full test suite. Bisect (Wolf Fence) Algorithm Mark a known‑good commit and a known‑bad commit. Checkout the midpoint commit. Test the bug; if it appears, move the “bad” marker to this commit, else move the “good” marker. Repeat until the offending commit is isolated. Delta Debugging Start with full failing input. Systematically remove chunks (e.g., halve the input). Test each reduced version. Keep the smallest subset that still fails; iterate until minimal. Record‑and‑Replay Record all inputs, nondeterministic events, and system calls during a run. Replay the recorded session in a debugger, stepping forward/backward as needed. --- 🔍 Key Comparisons Interactive Debugging vs. Post‑mortem Debugging Interactive: live stepping, breakpoints, real‑time state inspection. Post‑mortem: analysis after crash using core dumps, logs, stack traces. Static Analysis vs. Dynamic Debugging Static: no execution, finds syntactic/semantic issues, may produce false positives. Dynamic: runs the program, sees actual behavior, can catch Heisenbugs. High‑level (Java) vs. Low‑level (C/Assembly) Debugging High‑level: built‑in exception handling, type checking simplifies locating bugs. Low‑level: memory corruption, undefined behavior often require specialized memory debuggers or hardware tools. API‑Based vs. Exception‑Based Anti‑Debugging API: queries OS for debugger presence. Exception: checks whether exceptions are being intercepted/modified. Remote Debugging vs. Local Interactive Debugging Remote: debugger runs on a different machine, communication over network; may add latency. Local: direct control, lower overhead, easier for step‑by‑step inspection. --- ⚠️ Common Misunderstandings “Print statements are safe” – they can alter timing, hide Heisenbugs, or change memory layout. Static analysis catches everything – it only finds patterns it knows; many logic bugs slip through. High‑level languages eliminate debugging effort – they still suffer from logical errors, race conditions, and mis‑used APIs. Bisect works on any bug – only effective when a bug correlates with a change in version control history. Anti‑debugging is always malicious – sometimes used legitimately for copy‑protection; but its presence does not guarantee a bug. --- 🧠 Mental Models / Intuition Divide‑and‑Conquer – treat the codebase like a tree; cut it in half repeatedly to isolate the faulty branch. Binary Search for Bugs (Bisect) – just as you search a sorted list, you can search commit history. Black‑Box Input/Output – think of the program as a function f(input) → output; simplify the input until the output misbehaves. Time‑Travel as Video Playback – imagine stepping backward in a video to see exactly where the scene changed. --- 🚩 Exceptions & Edge Cases Heisenbugs – may disappear when you add breakpoints or extra logging. False Positives – static tools can flag correct code; always verify with a compile/run test. Hardware Breakpoints Limit – some CPUs expose only a few hardware watchpoints; may need software breakpoints instead. Timing Checks – can be fooled by system load spikes; not reliable as sole anti‑debug indicator. Remote Debugging Over Unreliable Networks – packet loss can corrupt state inspection. --- 📍 When to Use Which Interactive Debugger – when you have a reproducible, deterministic bug and need fine‑grained state inspection. Post‑mortem (core‑dump) analysis – when the program crashes without a chance to attach a debugger. Bisect – when you suspect a recent commit introduced the defect and you have a reliable test script. Delta Debugging – for large, complex inputs where manual reduction is impractical. Record‑and‑Replay – for intermittent, nondeterministic bugs (race conditions, timing‑related). Static Analysis – early in development to catch obvious misuse (uninitialized variables, type errors). Remote Debugging – when the target runs on a different OS/hardware or in production environment. --- 👀 Patterns to Recognize Intermittent failures after a specific code path → suspect race conditions or Heisenbugs. Performance hot‑spot with high CPU time → use activity tracing or profiling. Repeated “null‑pointer” crashes after a recent refactor → likely introduced by a recent commit → bisect. Core dump consistently points to the same library function → focus on that module’s recent changes. Sudden surge in static‑analysis warnings after a large merge → review the merge for false positives. --- 🗂️ Exam Traps Choosing “static analysis” as the answer for “how to find a runtime memory corruption” – static tools rarely detect runtime memory corruption; use memory‑debuggers or post‑mortem analysis. Selecting “print statements” over breakpoints for a timing‑critical bug – prints can alter timing and hide the bug. Assuming “remote debugging” eliminates the need for any network security considerations – remote connections can be intercepted; proper authentication is required. Confusing “anti‑debugging” techniques with legitimate debugging features – they are detection mechanisms, not tools for fixing bugs. Believing a “false positive” means the tool is broken – it simply means the rule is over‑broad; you must verify manually. ---