9.5 Display execution messages

9.5 Display execution messages

9.5.1 Basic tactic

Insert a statement in the source to print a message when a code block is executed, which lists the procedure name and some locality identifier.

9.5.2 Purpose

Determine the control-flow path taken by the program when processing a given set of inputs.

9.5.3 Questions answered

• Was the code block ever executed?

• How many times was the block executed?

9.5.4 Potential problems

• If the problem is caused by stack or heap corruption, the presence of an output statement may cause the symptom to disappear. This is because the runtime library that generates the output 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 an output statement may cause the optimizer not to perform the offending optimization or to perform it differently.

9.5.5 Refined tactics

1. Rather than trace code blocks, insert print statements right after entry to a procedure and right before exit from that procedure.

2. In addition to inserting the print statement, do the following:

   • Insert a statement to initialize a variable.

   • Insert a statement to increment the variable each time a block is executed.

   • Insert a statement that tests the variable and prints a message if it has been executed a specific number of times.

3. Insert statements in the source to print the values of all of the variables used to determine whether the block is executed.

4. In addition to the inserted print statement, do the following:

   • Add an execution option to the program.

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

9.5.6 Related tactics

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

  • Set a breakpoint at the code block of interest.

  • Step through execution.

  • Insert a statement to initialize a variable.

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

  • Set a breakpoint at the code block of interest.

  • Add a command list to the breakpoint that increments the added variable.

  • Set a conditional breakpoint at that code block, which will execute when the added variable reaches a specific value.

  • Add a command list to the breakpoint that prints a message and continues execution.

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

  • Set a breakpoint at the start of the code block of interest.

  • Add a command list to the breakpoint that prints the values of all of the variables used to determine whether the block is executed.

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

  • Set a conditional breakpoint at that code block, which will execute if the execution option was used.

  • Add a command list to the breakpoint that prints a message and continues execution.

9.5.7 Choosing tactics

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

• No high-level debugger is available.

• You don’t want to have to interact with a high-level debugger.

• It is quicker to recompile with a new statement inserted than to recompile, relink, and start up with a high-level debugger.

• You want a file containing a listing of every time certain code blocks are executed.

Use refined tactic 1 when the code block of interest will be executed many times.

Use refined tactic 2 when the code block of interest will be executed many times, and the statement controlling the block contains a complex Boolean statement.

Use refined tactic 3 when compile or link times are relatively long or when you anticipate wanting to display this variable again in the future.