9.15 Use runtime stack checking

9.15 Use runtime stack checking

9.15.1 Basic tactic

Use compiler options to generate runtime checking of stack integrity.

9.15.2 Purpose

Determine whether stack corruption is occurring.

9.15.3 Questions answered

• Which procedure’s stack frame is being corrupted?

• When is the stack being corrupted?

9.15.4 Potential problems

• If your program makes a lot of procedure calls, checking the integrity of the stack on every call could slow down execution significantly.

• Some compilers may not support this option.

9.15.5 Refined tactics

None.

9.15.6 Related tactics

• Insert calls to user procedures to perform runtime checking of stack integrity.

• Use a high-level debugger or interpreter to do the following:

  • Set a breakpoint at a place where you would like to begin checking the integrity of the stack.

  • Add a command list to the breakpoint that calls a user procedure to perform checking of stack integrity, and then continue execution.

9.15.7 Choosing tactics

Use this tactic when one of the following conditions is true:

• The compiler doesn’t generate runtime stack checking by default.

• A bug occurs when the program is run standalone, but not when it’s run under a debugger.

• A bug occurs when the program is run under one user account and environment, but not when it’s run under another.

Use this tactic at least once before the program is put into production, as an additional testing strategy.

9.15.8 Language specifics

• C++: The stack pointer can be corrupted by bad pointer references.

• Java: Java guarantees stack integrity, so the tactic is unnecessary.

• C: The stack pointer can be corrupted by bad pointer references.

• Fortran: Stack integrity can only be compromised by invalid array subscripts.