embedded software boot camp

Bug cluster phenomenon

Wednesday, October 8th, 2008 by Nigel Jones

I was debugging a piece of code recently when I realized that there was a scenario, albeit unlikely, in which a divide by zero could occur. Rather than just fix the bug and move on, I invoked what I call the “bug cluster phenomenon” rule. What you may ask is this rule? Well it has two variants. The first is as follows:

“Where there is one bug, there is usually another”. I’ve observed this phenomenon over many years. What seems to happen is that when I (or anyone else for that matter) is generating a block of code, I get interrupted, or I’m tired or my focus is elsewhere. As a result, when I create one bug, I usually create several others while I am at it. Thus when I find a bug in a function, I always assume that it has company near bye. In short, finding a bug in a function always triggers a top to bottom review of that function and its neighbors. This has dramatically reduced my debugging time over the years – and I strongly recommend you adopt it.

The second variant of the rule is as follows:

“Logical errors normally have company”. I’ve also observed this phenomenon over many years. In this case, it seems that if you have made a particular error in logic in one place in the code, the chances are you have made the same error elsewhere. In the case of the divide by zero issue mentioned in the introduction, this prompted me to wonder if I had any other possible divide by zero errors lurking in my code. As a result, I performed a search through the entire project – and sure enough I found a few other cases where there existed the possibility of a divide by zero error. Thus finding one bug caused me to fix several. That’s efficient debugging!

Incidentally, I was able to quickly find all the divisions in my code because I am absolutely anal about having a space on either side of an operator. Thus, I needed to search for only two strings – ” / ” and ” /= “. I’ve observed that many people are lackadaisical about this, such that you’ll often see expressions such as “y=a/b”. These people have no option other than to search either for just “/” – which of course returns every line with a comment, or they have to construct a more sophisticated regular expression search – which again takes time and is error prone.

Thus I have three pieces of advice to pass on:
1. When you find a bug, look nearby for more.
2. If the bug was of a particular class of bug, then search your code to see if you had made the same mistake elsewhere.
3. Write your code so that it is trivial to search for certain constructs. It will save you time in the long run.


6 Responses to “Bug cluster phenomenon”

  1. Paul N. Leroux says:

    Hi Nigel. Your advice reminds me of an old proofreader’s trick: When you find one typoe, look for another neerby. :-)- Paul

  2. Niall Murphy says:

    Interesting point about being able to search for the operators. Similarly, I think the biggest advantage of new-style C++ casts is that they contain a unique string that can easily be searched (e.g. static_cast). In C style casting, if I decided to investigate all of the casts to unsigned int I would try to search for(unsigned int)(x)but it would be hard to be sure of the spacing at the round braces will match and I might miss a related one like(const unsigned int)For all the fancy browsing tools out there, a simple text search is often the best way to track down certain operations, and finding casts by searching for “_cast” or “static_cast” is handy, because like the divisions you describe, casts are often the cause of bugs and require a second look.

  3. Anonymous says:

    nice advice

  4. Uhmmmm says:

    A regexp to exclude comments would look something like:[^*/]/[^*/]A quick grep of some sourcecode I have lying around shows that it works, but it also catches a few file paths (#include directives) and some text in comments. But the vast majority of what it finds is division.Granted, it’s more complex than searching for ” / ” and ” /= “, but not significantly so if you know even basic regular expressions.

  5. Nigel Jones says:

    May be it’s just me, but I find great difficulty in remembering regular expression syntax. The problem is that I just don’t use them often enough.

  6. Daryl Fortney says:

    I have found that using automatic source code style formatters (ctl + shift + f in eclipse) helps out here. no need to worry about style while writing and then just hit that at the end and everything gets cleaned up. a second benefit is people actually think i am careful about my coding 😉

Leave a Reply