1.2 Software Debugging — Essence, Origins, and Myths

If the previous section was about building the physical space of our lab, then in this section, we first need to align on a fundamental understanding: in this space, what exactly are we up against?

As software professionals, when we say "bug," we mean those flaws, errors, or defects in code — anything that causes software to deviate from its expected behavior.

And as developers, a massive and core part of our work is dedicated to hunting these things down and fixing them. Our goal is simple: to push software as close to "flawless" as humanly possible, making it run as precisely as the design蓝图 dictates.

The Chicken or the Egg?

This sounds perfectly reasonable — but to fix it, you have to find it first. This is where the first counterintuitive truth emerges:

For non-trivial system-level bugs, you often have no idea they exist until some event "blows" them into the open.

It's like sitting on a landmine with an unknown timer. This uncertainty is deeply unsettling. So, as a rational industry, shouldn't we have a disciplined methodology to root them all out before a product ships?

Absolutely, and we do. This is quality assurance, commonly known as testing.

Although we sometimes look down on testing work (feeling it lacks the "technical depth" of writing core code), it remains one of the most critical phases in the software lifecycle — arguably the most important. Think about it: would you board a new aircraft model that had never been tested? Unless you're the test pilot betting your life on it, the answer is definitely "no."

Testing is the last line of defense, designed to intercept bugs before they escape into the world.

When the Line of Defense Falls

Now, back to our scenario.

Suppose the defense has failed — QA let a bug slip into production, or the kernel module you're developing suddenly crashes under some extreme edge case.

Now the bug has been identified (maybe someone even filed a ticket for you). At this point, your core mission shifts: from "discovering it" to "dissecting it." You need to pinpoint the root cause — not just "it crashed," but "why did it crash on this exact line, under this exact condition?"

This is no easy task. Most of this book is essentially about one thing: how to use tools, techniques, and the right mindset to locate that root cause.

Once you've found the root cause and truly understand the underlying mechanism, fixing it is often trivial — just changing a few lines of code. What really makes you tear your hair out is finding exactly which few lines to change.

This process — from identifying a bug, using tools and deep reasoning to locate the root cause, and finally fixing it — is collectively known as debugging.

Debugging: The process of identifying a defect, determining its root cause, and subsequently fixing it.

The Name's Origin: That Moth

Since we're on the topic of "debugging," we have to mention the widely circulated story.

The popular account goes that on Tuesday, September 9, 1947, Rear Admiral Grace Hopper of Harvard University (then still a colonel) and her team found a moth inside the relay panel of the Mark II computer.

Because the bug had jammed the relay, it caused a system fault. They taped it into the logbook and labeled it "First actual case of bug being found." They removed the moth, the system returned to normal — and so, they had "de-bugged" the system!

It's a great story, highly visual, and it has since become a legend in computer science.

Figure 1.1 — The famous moth (Courtesy of Naval Surface Warfare Center, Dahlgren, VA, 1988. U.S. Naval Historical Center Online Library Photograph NH 96566-KN. Public Domain)

But as rigorous engineers, we need a reality check:

First, Admiral Hopper herself later clarified that she didn't coin the term "debug"; Second, etymological research suggests the term likely originated in the aviation field (referring to mechanical failures in aircraft engines).

While the moth was indeed real and was the first physically documented computer bug, the concept of "debugging" existed before it appeared. However, given how vivid the story is, the term became firmly embedded in our jargon.

The Real-World Cost

Now that we understand what bugs and debugging are, let's zoom out a bit.

This isn't just a matter of writing bad or good code. In the following sections, we'll look at several real-world tragic cases to see what happens when a minor software bug appears in the wrong place at the wrong time — it doesn't just take down servers, it can cause massive loss of life and property.

These cases remind us: debugging isn't a puzzle game — it's investigating hidden dangers in a system.