/Debugging

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

The Heisenbug Server

- Oren Eini tl;dr: "A user reported that they observed nodes in the cluster “going dark”. Basically, they would stop communicating with the rest of the cluster, but would otherwise appear functional. Both the internal and external metrics were all fine, the server would just stop responding to anything over the network. The solution for the problem was to restart the service, but the problem would happen every few days."

featured in #384

A Beginner’s Guide To Chrome Tracing

- Nolan Lawson tl;dr: Chrome tracing lets you record a performance trace that captures low-level details of what the browser is doing. It’s mostly used by Chromium engineers themselves, but it can also be helpful for web developers when a DevTools trace is not enough. This post is a short guide on how to use this tool, from a web developer’s point of view. I’m not going to cover everything – just the bare minimum to get up and running."

featured in #383

A Debugging Manifesto

- Julia Evans tl;dr: Julia discusses the attitude and approach to take when debugging, explaining the following: (1) Inspect, don’t squash. (2) Being stuck is temporary. (3) Trust nobody and nothing. (4) It’s probably your code. (5) Don’t go it alone. (6) There’s always a reason. (7) Build your toolkit. (8) It can be an adventure.

featured in #375

Tips For Analyzing Logs

- Julia Evans tl;dr: 14 useful tips including the following: (1) Search for the request’s ID - often log lines will include a request ID and searching for the request ID of a failed request will show all the log lines for that request. (2) Build a timeline - keeping all of the information straight in your head can get confusing, so keeping a debugging document where I copy and paste bits of information.

featured in #374

Twenty Five Thousand Dollars Of Funny Money

tl;dr: "I had been at the company something like six weeks and had changed a line of source code to fix a bug (logging), to uncover another bug (wrong argument count), to enable yet another bug (wrong units, and zero type safety) that gave 25 grand worth of funny money to anyone who clicked! And I had clicked! And I got a friend to click! And other people got it too!"

featured in #372

Debugging Mysterious Traffic From Boardman, OR

tl;dr: "A quick Google search revealed that Boardman, OR hosts a large AWS data center. Turns out that because Boardman has access to electricity from hydropower, it is cheaper than other data centers and is therefore preferred by many."

featured in #369