Debugging an embedded system is a necessary evil. Debugging can range from very simple bugs that take nearly no time at all to debug all the way through some of the most complex and frustrating bugs known to man. There are four different categories that any embedded software bug falls into and while some of these categories may seem bizarre, the reader can rest assured that each category is indeed possible.
Bug type #1 – Bohrbugs
If an embedded system is going to have bugs, a developer would prefer them to be classified as Bohrbugs. Bohrbugs are software bugs that are easily reproducible when the software is ran in similar conditions. Since a develop can reproduce the bug, digging in and finding the root cause is generally straight forward. The Bohrbug is named after Niels Bohr who proposed a model for the atom that was easy to understand.
Bug type #2 – Heisenbugs
Every now and then a developer will encounter a bug that as soon as the bug is observed disappears and every attempt to reproduce the bug fails. A developer may decide that it was a fluke and the system is find but in reality the system has a Heisenbug. A Heisenbug is a bug that changes their behavior and property once they are observed in the system. Attempts to isolate and debug the issue is often difficult and fleeting. Heisenbugs are often a sign that there is a race condition somewhere in the code. Slight modification to the code, timing or connecting a debugger to the system magically make the bug disappear. Heisenbugs are named after Werner Heisenberg who is well known for his uncertainy principle in quantum mechanics.
Bug type #3 – Schroedinbugs
Developers will occasionally be working on an embedded system that appears to be working flawlessly. A developer might be performing a code review or adding a new feature and then suddenly discovers a bug in the code that has never exhibited itself the system. Upon a review of the system behavior, the developer discovers that the system was NOT working correctly the whole time! Bugs that occur only when you look at them are known as Schroedinbugs. The system works fine until the bug is discovered and then only once the bug is observed does it suddenly exhibit consistent behavior. The Schrodinbug is named after Erwin Schrodinger for his observational thought experiment about a cat being half alive and half dead until it is observed.
Bug type #4 – Mandelbugs
Developers will sometimes encounter a bug that appears to be simple and Bohrbug like. After a minor change to the code the bug seems to be resolved but a new bug is discovered from fixing the first. Fixing the second bug results in a third and fourth bug appearing in the system. Then a fifth, sixth and seventh! No matter what a developer does the solution to one bug seems to fracture the bug resulting in more bugs and issues in the system. These bugs that seem to fracture or appear chaotic are known as Mandelbugs after Benoit Mandelbrot who is the father of fractal geometry. The idea is that the bugs while seemingly simple are actually the result of complex interactions in the system that the developer doe snot fully comprehend. Hence fixing a problem in one area causes problems in another.
Every software bug known to mankind falls within one of these four bug categories. While some of these categories may seem impossible, I’ve encountered bugs that fall into all four! The most common and hoped for bug is of course the Bohrbug. Keep these categories in mind the next time a system needs debugging. Classifying the bug category can help lead a developer to the potential cause.