Debugging by Thinking: A Multidisciplinary Approach (HP Technologies)

9.12 Check data structures

9.12.1 Basic tactic

Insert calls to procedures that check the validity of user data structures.

9.12.2 Purpose

Identify invalid data structures.

9.12.3 Questions answered

• Which data structures become invalid?

• When do those data structures become invalid?

• What element of the data structure becomes invalid?

9.12.4 Potential problems

• Checking complex data structures can be computationally expensive.

• If the problem is caused by stack or heap corruption, the presence of a call to a checking procedure may cause the symptom to disappear. This happens because the checking procedure will shift things on the stack and may allocate memory on the heap.

• If the problem is caused by optimizations performed by the compiler, the presence of a call to the checking procedure may cause the optimizer not to perform the offending optimization or to perform it differently.

9.12.5 Refined tactics

In addition to the inserted call statement, do the following:

• Add an execution option to the program.

• Insert a conditional statement that executes the validation only if the execution option was used.

9.12.6 Related tactics

Implement data structures that use pointer redundancy to enable error detection and correction.

9.12.7 Choosing tactics

Do a complete test run with all data-structure checking turned on at least once before the program is put into production.

9.12.8 Language specifics

• C++: Data structures that use pointer redundancy can be helpful.

• Java: Since memory can’t be corrupted in Java, data structures that use pointer redundancy checking aren’t necessary.

• C: Data structures that use pointer redundancy can be helpful.

• Fortran: Due to the nature of pointers in Fortran 95, it’s harder to corrupt their values than in C or C++, but it can be done if array subscripts go past their bounds unchecked.