The anatomy of a bug part I

on Jul 16, 15 • by Chris Gottbrath • with 2 Comments

Knowing the component parts of a bug helps talk about them and solve them smartly and efficiently. Read on to be a better debugger...

Home » Software Testing » The anatomy of a bug part I

Know thy enemy

As software developers we deal with bugs all the time. We know one when we see one, right? Is there any value, then, in looking at all of the different kinds of information that comprise a software bug? Since we spend so much time preventing, identifying, and correcting bugs I think it is valuable to spend a bit of time to think about the component parts of a bug. If we do, then we may find ourselves talking and reasoning more precisely about how to approach debugging, about the effort that goes into debugging, and how to plan our processes and procedures so that as individuals or teams we can be more effective at creating bug-free software.

In the first part of this blog, I’ll discuss the components of a bug up to identifying the actual defect. Next time, I’ll explain what happens after this step, including the problem resolution.

The bugs generally have the following features:

Sighting – The sighting is the event that lets you know that the bug exists; it could be a test failure, a customer report of a problem, a crash, or a hang. The information that is captured when the bug is first sighted is almost always insufficient to know very much about the cause or behavior of the defect itself.

Symptom – The symptom is the specific way the program isn’t behaving as expected. I think of it as “the program should do X and instead it does Y.” It is more specific than the sighting because often when a program first fails the person who makes the sighting isn’t paying attention to it at a level to give a clear symptom. So it may take trying it two or three times before the symptom becomes clear.

Reproducer – This is the set of steps necessary for an arbitrary user to reproduce the symptom with at least some probability. It can include manual inputs and settings, data files or database contents, or configuration details.

Description – The description is the full write up of the bug and it should include the symptom as well as some kind of articulation of the context in which the symptom can be seen. If a full reproducer is available then including that is ideal. Usually the more precise the information the better but in practice, sometimes less than perfect bug descriptions are what you work with. The description often starts with minimal information and gets more precise as more is learned.

Failure – This is usually related to the part of the program that is responsible for doing what the program does when the symptom occurs. A program may, for example, crash because it dereferences an invalid memory address. Often it isn’t too hard to find the failure part of a bug — but then you start looking for the cause (where did the invalid address come from?)

Cause – Effect Chain – There may be one or more steps of cause -> effect that separate the initial defect in the code from the final failure that lead to the symptom.

Defect – This is the actual mistake in the program itself. It is the cause at the beginning of the effect chain. Sometimes it is a single line, word, or even character. Generally this can only be determined through a process of analyzing the behavior of the program to find each link in the cause – effect chain.

So there we have the anatomy of a bug up until the defect. Join me next time as we dig deeper into why the defect occurred and the problem resolution steps that come after it.

Read part two of this blog now

For more information on the tools and techniques that simplify and assist with the debugging process, visit

Learn more:

• Watch this video to learn about debugging numerical simulations on accelerated architectures.

• Read this datasheet to learn more about TotalView, a scalable and intuitive debugger for parallel applications written in C, C++, and Fortran.

Related Posts

2 Responses to The anatomy of a bug part I

  1. Greg Colvin says:

    When I worked in the Oracle kernel it was often impossible to replicate a crash at a customer site. We made sure our code was well instrumented, so that our logs provided useful clues. And we became very good at sniffing stack traces and core dumps. If we were very lucky this information was sufficient to identify the bug. At the least, it might be enough to construct a reproducible test case for debugging. Failing adequate information at the time of sighting we were usually helpless.

    • Greg,

      Thanks for the feedback. The scenario you describe is interesting and particularly challenging. I think that in situations where the defects have a low frequency of reoccurrence it is very appropriate to code defensively up front and make sure that logs are complete enough but it seems like that could itself be tricky. Do you mind if I ask a few follow-up questions?

      1. Were you able to get enough log messages in that the initial runtime log would actually be enough for you to track down the problem? Did you have challenges with data volume in the log? I’ve worked with teams (internal and external) that use logging very effectively but generally we find that we need to keep logging as “optional” and enable it selectively after the fact when we are trying to get the problem to happen a second or third time. So we get a high data volume but only when tying to track down a problem. It sounds from your note like you had only a single shot at the problem, which would make the data volume trade offs especially challenging.

      2. What was it about the situation that made it so difficult for customers to replicate the issue?

      3. Were there any techniques or rules of thumb that you developed to make it easier to create “just the right” log contents? Did you concentrate on control flow? Consistency checks? Assertions?

      4. Where there any techniques that you developed to make it easier to work with stack traces and core dumps?

      Thanks again for sharing your insights!


Leave a Reply

Your email address will not be published. Required fields are marked *

Scroll to top