/Debugging

Lessons From Debugging

- Matt Rickard tl;dr: (1) Reproduce with the smallest example. In the simplest environment. (2) Read and re-read the error statement. Read the stack trace. Add more logging if you don’t know where the error is thrown. (3) Change one thing at a time. (4) Divide and conquer. Sometimes that means binary search on good/bad commits. Other times isolating the problem. (5) Be open to debugging in different environments. (6) State your assumptions. (7) Get a second set of eyes on it. (8) If you're debugging some stateful code, think about \_how\_ you ended up at that state. A recipe that (reproducibly) gets you to that state is often the path to fixing it. (9) Look at the logs, all the logs. (10) When in doubt, start with the most recent changes, especially dependencies changes.

featured in #453

A Systematic Approach To Debugging

- Nicole Tietz-Sokolskaya tl;dr: Nicole’s process involves six steps, each of which she expands on: (1) Identifying the symptoms. (2) Reproducing the bug. (3) Understanding the systems. (4) Forming a hypothesis about the bug's location. Instead of randomly searching through the code, the author suggests forming a hypothesis about where the bug might be located. This narrows down the search and makes the debugging process more efficient. (5) Testing the hypothesis. (6) Fixing the bug. "If you don't understand the bug behavior, you have no hope of knowing if you've fixed it or not."

featured in #448

Invariants: A Better Debugger?

- Marc Brooker tl;dr: Marc emphasizes the use of invariants, conditions that must hold true during or after code execution, as a powerful debugging tool. Through examples, the author illustrates how developers can use invariants to reason about complex algorithms and distributed systems. Invariants offer a deterministic, repeatable way to understand and ensure correctness, making them a valuable alternative to traditional debuggers.

featured in #437

12 Debugging Tools I Wish I Knew Earlier

- Jordan Cutler tl;dr: The first 2 are: (1) Git bisect: Run you through a binary search process between the “good commit” and the “bad commit” until it finds the commit the bug started happening. (2) “Binary search commenting”: Commenting out sections of the code and replacing it with a hardcoded value to narrow in on where the problem is.

featured in #434

The Curious Case Of A Memory Leak In A Zig Program

- Krut Patel tl;dr: “This is a small exposition on an unexpected "memory leak" I encountered when writing a Zig program. We will mainly focus on a very simple allocation pattern and see how it causes a "leak" when using a particular allocator from Zig's stdlib.”

featured in #399

What A Good Debugger Can Do

- Andy Hippo tl;dr: Andy discusses various free and commercial products as examples to raise awareness and challenge the popular belief that “debuggers are useless” discussing modern tools that manage issues around breakpoints, data visualization, express evaluation, concurrency, hot reload, and more.

featured in #397

My Hardest Bug Ever

- Dave Baggett tl;dr: Dave, a video game developer, discusses the hardest bug he’s come across and how we went about debugging it. “Among other things, I wrote the memory card code for Crash Bandicoot. For a swaggering game coder, this is like a walk in the park; I expected it would take a few days. I ended up debugging that code for 6 weeks. I did other stuff during that time, but I kept coming back to this bug - a few hours every few days. It was agonizing.”

featured in #395

Improve Your Debugging By Asking Broad Questions

- Hillel Wayne tl;dr: “Most of the time we ask narrow questions which are helpful when confirmed and not-helpful when rejected. If you make a lot of wrong predictions, then debugging boils down to guess-and-check. If you instead ask broad questions, you learn less when they’re true but more when they’re not. Then you iteratively close in on the actual source of the bug.”

featured in #393

How A Single Line Of Code Brought Down A Half-Billion Euro Rocket Launch

- Michael Stroe tl;dr: "So what was the ultimate cause of this very short, very expensive and catastrophic flight? A line of code converting a 64-bit floating point to a signed integer, which led to an overflow passed directly to the main computer, that interpreted it as real data.”

featured in #389

How To Debug

- Phil Booth tl;dr: These steps are not specific to a particular language or paradigm, Phil's explains each of the following debugging steps: (1) Reproduce the bug. (2) Reproduce it again. (3) Don't reproduce it. (4) Understand the code. (5) Observe state. (6) Write down what you (think you) know. (7) Rule things out. (8) Walk the dog. (9) Rewrite a component. (10) Write a failing test case. (11) Fix it.

featured in #384