Types of bugs!

Tim Gray, in his popular paper originally proposed the classification of bugs as Bohrbugs and Heisenbugs, named after well known scientists. Today, there are more bugs types known to us, so we look at other two categories of bugs.

Bohrbugs: Most of the bugs that we come across are reproducible and are known as Bohrbugs. These are named after Niels Bohr, who proposed a simple and easy to understand atomic model in 1913. In Bohr’s model, things like path and momentum of an electron in an atom are predictable. Similarly, Bohrbugs are predictable— you can reproduce them if you run the software with similar conditions. For example, if program crashed with null-pointer access, it always crashes there for a given input; so you can easily reproduce it.

Heisenbugs: All experienced programmers have faced situation where the bug that crashed the software just disappears when the software is restarted. No matter how much time and effort is spent trying to reproduce the problem, the bug eludes us. Such bugs were named Heisenbugs, after Werner Heisenberg, who is known for his ‘uncertainty principle’. According to his theory, it is not possible to accurately or certainly determine the position and velocity of the an electron in an atom at a particular moment. When bugs change there behavior when you try to debug, probe or isolate, they are called Heisenbugs. It can happen when you use uninitialized variables. When the program is run, it will access the uninitialized variables, and hence result in a bug. However you try to debug the program, it might work just fine, because many debuggers initialize uninitialized variables to zeros, and you might not hit the problem !

Mandelbugs: The cause of the bug is too complex to understand, and the resulting bug appears chaotic, it is called a Mandelbug. These are named after Benoit Mandelbrot, who is considered the father of fractal geometry (fractals are complex and self-similar structures). A bug in an operating system that depends on scheduling is an example of a Mandelbug.

Schroedinbug: Sometimes, you look into the code, and find that it has a bug or a problem that never should have allowed it to work in first place. When you try out the code, the bug promptly shows up and software fails! Though it sounds very uncommon, such bugs do occur and are known as Schroedinbug. They are named after scientist Erwin Schroedinger, who proposed theoretical ‘cat experiment’. In quantum physics, quantum particles like atoms could exists in two or more quantum states, but he suggested that in more classical objects like a cat which is made up of many atoms, existing in two or more was impossible. He theorized about a scenario in which a cat is kept in as sealed chamber, with a vial of poison (attached to a radioactive atom). If the atom decayed, the vial would be smashed and the poison would leak, killing the cat. But with chamber sealed, there would be no way to know whether the cat was dead or alive. So till the chamber is opened, theoreatically, the cat could be in either of two states – dead or alive. In quantum physics, this is called a ‘super-positional state’, where cat is both dead and alive!

Coming back to bugs, by merely observing the problem in the code, you change the outcome – either the software works or breaks. So these kinds of bugs are known as Schroedinbug.

There are other types of bugs that didn’t come under these categories. For instance, ‘aging-related bugs’ occur only after the software runs for a long time.

5 Comments

  1. Posted December 30, 2011 at 8:10 am | Permalink

    Really nice article, could you elaborate a little on Schroedinbug. I did not understand its scenarios.

    • Rahul Bedarkar
      Posted January 2, 2012 at 12:08 am | Permalink

      Actually, Schroedinbug kinds of bugs are seen very often🙂 Let me give you some examples.

      Example 1:

      void insert()
      {
      Node *ptr; // Line 1
      ptr->something = 10; // Line 2
      }

      This example is very similar to Bohrbugs. Here looking at code you can say that there is
      segmentation fault.

      Example 2:

      void foo()
      {
      unsigned int x;
      x = 10;
      if (x < 0) // line 3
      {
      return 0;
      }
      }

      At line 3 you are trying to compare x < 0. But X is something unsigned. Hence you will get compile time error.

      Many times these kinds of bugs are compile time rather than run time.

      Let me know if you thought of similar examples.

  2. Rahul Bedarkar
    Posted December 30, 2011 at 8:34 am | Permalink

    @ shravanaras ya sure

  3. Ashwin Tumma
    Posted January 1, 2012 at 6:12 am | Permalink

    Indeed an awesome article Rahul! Thanks for the same.
    Truly, even I have experienced these kind of bugs.

    Query: Same as posted by Shravan.

    • Rahul Bedarkar
      Posted January 2, 2012 at 12:08 am | Permalink

      Actually, Schroedinbug kinds of bugs are seen very often Let me give you some examples.

      Example 1:

      void insert()
      {
      Node *ptr; // Line 1
      ptr->something = 10; // Line 2
      }

      This example is very similar to Bohrbugs. Here looking at code you can say that there is
      segmentation fault.

      Example 2:

      void foo()
      {
      unsigned int x;
      x = 10;
      if (x < 0) // line 3
      {
      return 0;
      }
      }

      At line 3 you are trying to compare x < 0. But X is something unsigned. Hence you will get compile time error.

      Many times these kinds of bugs are compile time rather than run time.

      Let me know if you thought of similar examples.


Post a Comment

You must be logged in to post a comment.
%d bloggers like this: