Monday, September 14, 2015

Software Defects

Defect-free software does not exist
Wietse Venema

However, that doesn't mean you shouldn't try your hardest. And give me a bug that fails spectacularly, those are usually the ones that are easiest to find. It's those little tiny errors that only occasionally show up that are the really hard ones.

When I first started programming, I was doing real-time, multi-processor, embedded systems. Now there were some bugs! I can remember spending more than a week trying to find a particularly pernicious one. Now we have source code debuggers, but back then all I had was the equivalent of the asm mode of gdb and debug writes to I/O ports or memory locations. I have been caught debugging and patching in some opcodes by hand into a C/C++ program to see if that would fix the problem. Old habits die hard.

At one point I was responsible for all of the I/O drivers of an MP/M system and had spent several days and a final 24 straight hrs the day before a demo trying to get it working. It seemed like the system would work just fine and then just lose its mind. We had to cancel the demo and I went home and slept, leaving as others were coming to work the next day. Eventually we found out that an interrupt routine was losing the carry bit in the accumulator (interestingly, that system and associated compiler did a inordinate amount of status checking using the carry bit).

64 bits worth of status and data in that processor and I was saving 63 of them. 98.4% accuracy was not good enough, it never is with computers.

A machine is an unforgiving executor of what we write, not what we mean, which is why many of us develop such a odd-ball sense of humor. You have to relieve the pressure somehow.

Anyone have or know of any great bug or bug hunting stories? Add them to the comment section. I would enjoy reading and learning from them. Meanwhile, check out the 500-mail email problem.

No comments:

Post a Comment