Use compiler options to generate runtime checking of stack integrity.
Determine whether stack corruption is occurring.
Which procedure’s stack frame is being corrupted?
When is the stack being corrupted?
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.
None.
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.
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.
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.