89.

Overview

When a program crashes due to corrupted data, the reason can be elusive. Often a program can crash dead in its tracks while manipulating its own internal data, even after working flawlessly for long periods. You've probably already encountered the Saboteur Data bug pattern. We discuss the syntactic and semantic reasons for it and offer potential methods for eliminating it.

Being an industrious developer, you've deployed one of your well-written and well-tested applications for several of your clients who needed better access to their massive stores of complex data.

For each client, the on-site testing period went off without a hitch. You're on your way to the bank, only barely thinking about the six-month software checkup, when your pager goes off. One of your clients ran a report using your software and bombed the system.

You rush to the site and run a random test. It works fine. You run another. No problems. You run hundreds more. Still no problem. You check on other clients who have been running this application full tilt for six months. You get no complaints.

Then, you repeat the report that caused the problem. Crash! What's going on?

You've just met the Saboteur Data, a bug pattern that can be the culprit behind this sort of crash. We explain why it exists and offer several methods to eliminate it—before and after it occurs. Here is the summary of the Saboteur Data bug pattern:

• Pattern: Saboteur Data.

• Symptoms: A program that stores and manipulates complex input data crashes unexpectedly while performing a task similar to other tasks that cause no problem.

• Cause: Either the syntax or the semantics of some of the internal data is corrupted.

• Cures and Preventions: Perform as many integrity checks on input data as possible, as early as possible. For persistent data that is already corrupt, walk over it and check for integrity.