/Debugging

Classifying Bug Reports With ChatGPT

- Rafael Quintanilha tl;dr: Rafael creates an automated workflow that: (1) Triggers on new bug reports. (2) Uses ChatGPT to classify the report based on the user description. (3) Updates the priority accordingly. (4) Sends a Slack notification if and only if the bug is deemed as Urgent.

featured in #504

A Very Subtle Bug

- Nelson Elhage tl;dr: "I like to say that complex systems don’t usually fail for complex reasons, but for the simplest, dumbest possible reasons – there are just more available dumb reasons. But sometimes, complex systems do fail for complex reasons, and tracking them down does require understanding across many of the different layers of abstraction we’ve built up. This is a story of such a bug."

featured in #466

67 Weird Debugging Tricks Your Browser Doesn't Want You to Know

- Alan Norbauer tl;dr: "A list of useful, not-obvious hacks to get the most out of your browser’s debugger. Assumes an intermediate-level-or-higher understanding of the developer tools." These include logpoints / tracepoints, changing program behavior, quick and dirty performance profiling, using function arity, using time. And more. 

featured in #465

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