Interlude: The Folklore of Debugging

Over the years developers have swapped stories around the virtual campfire about weird bugs and wonderful debugging techniques. I thought it might be entertaining and even instructive to gather a few of these stories in one place.

The Phase of the Moon Bug

Developers are prone to blaming their bugs on freak occurrences or unusual conditions. Anything that can direct the blame away from their code is fair game for a developer frantic to explain away a tenacious bug. The cry goes up: "I can't reproduce the bug, so it must have been a full moon/cosmic rays/in an older version/already fixed/a problem between the keyboard and chair ."

One such bug struck two MIT researchers who were writing some code that generated comments into a file of LISP forms. Normally the code worked fine, but at regular times in each month the resulting LISP forms would fail to compile. The Twilight Zone feeling arrived when it became clear that the program only failed during certain phases of the moon!

The cause of the bug was that the comments being written included the phase of the moon as part of their text. This meant that the comment lines were of variable length. At certain times of the month, the comment line length would exceed the page width of the LISP form. This automatically ran the comment onto a new line, which was then no longer perceived as a comment but as executable code, thus causing the compilation failure.

So there you have it: Finally a bug that really can be blamed on the full moon.

The 49.7 Bug

This bug was originally thought to be mythical, but it is now recognized as a real bug in a device driver that is part of Microsoft Windows 95. The rumor was that the maximum number of days that Windows 95 could operate continuously was 49.7 days. This was not verified for a while, possibly because uptimes of longer than a month are rare in the wild. However, this has now been confirmed as a timing problem in an obscure device driver.

For those of you who are curious and still have access to this rapidly fossilizing operating system, the details of the offending device driver are as follows :

 Date      Time       Version       Size      File name ---------------------------------------------------------- 6/23/98   2:44pm     4.00.951      18,570    Vtdapi.vxd 

The Musical "Bug"

This next curiosity is actually a feature rather than a bug. Microsoft started receiving the occasional support call about users complaining that their computer was randomly playing classical music! Heavy medication was the obvious diagnosis, or perhaps even a virus, but this "bug" turns out to have an interesting origin.

From 1997 onward, the Award/Unicore company produced several PC BIOSs and motherboards containing an electronic hardware-monitoring component. This component was designed to detect whether the CPU fan was failing or had failed, and whether power supply voltages had drifted out of tolerance. If the component spotted any such problem, it signified the discovery by playing either "Fur Elise" or "It's a Small, Small World."

If you're having a hard time believing this, take a look at the Microsoft Knowledge Base article number Q261186.

Deliberate Excel Bug

If you type the formula =DATE(1900,2,29) into any version of Excel, this date will be accepted even though it's actually invalid ”1900 is definitely not a leap year. In case you're interested, the rule is that all years divisible by 4 are leap years, except those years divisible by 100; the exception is that all years divisible by 400 are leap years.

The reason for this Excel bug appears to be a deliberate compatibility decision by the Excel team. Back when Lotus 1-2-3 was by far the most popular spreadsheet application available, the Lotus developers accidentally created this leap year bug. In order to maintain compatibility with the Lotus spreadsheet application and to be able to use the same date serial number scheme, the Excel developers decided to copy the same bug. In fact, all days of the week prior to 1 March 1900 are reported by Excel as one day earlier than they actually are. Microsoft claims that fixing this bug would create many more problems, presumably in existing spreadsheets.

The Margarita Bug

At an appliance company that builds blenders , a small group of developers is responsible for testing the blenders, which the lucky fellows do by making margaritas. For a while, in a politically correct environment, they only used virgin margaritas (those made without any alcohol). This changed rapidly after the first of a new series of blenders all failed. Apparently, the alcohol depresses the freezing point of the mix, which loaded the electric motor more heavily, which in turn burned out the drive transistors . So now the poor fellows are forced to test using real margaritas.

The Lunch Game

I don't know who invented this game, but several developer shops now play it. The idea behind the game is rather simple. Whenever somebody creates a new procedure, that person has to add a random day of the week in the header comments of the procedure.

After the procedure has been deployed into production and a bug has been found in it, the person finding the bug looks at the day of the week in the header. If somebody other than him- or herself wrote the offending procedure, and the day in the header is the current day, the person who wrote the procedure has to buy lunch for the developer who fixes the bug.

This has two interesting results. First, it encourages extensive testing for bugs, and second, it encourages you to fix any bugs that you find as soon as possible. This is because if the bug is in a procedure that you wrote, fixing it means that you avoid having to buy lunch for somebody else. If the bug is in somebody else's code, fixing it means that somebody buys lunch for you.