9.6 Display procedure arguments


9.6 Display procedure arguments

9.6.1 Basic tactic

Insert statements in the source to print the values of arguments on entry to a procedure.

9.6.2 Purpose

Determine the values that are inputs to each procedure.

9.6.3 Questions answered

  • What were the values of all arguments each time the procedure was invoked?

  • Was the procedure ever invoked?

  • How many times was the procedure invoked?

9.6.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.

  • Some languages allow arguments to be omitted. Your output statement should be guarded so that it doesn’t refer to a nonexistent argument.

9.6.5 Refined tactics

  1. Print relevant global variables as well as arguments.

  2. Print function results before returning. This is made much easier if the function is coded to have a single exit.

  3. In addition to the inserted print statements, do the following:

    • Add an execution option to the program.

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

9.6.6 Related tactics

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

    • Set a breakpoint at the entry to the procedure.

    • Print the values of the arguments if the breakpoint is taken.

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

    • Set a breakpoint at the entry to the procedure.

    • Add a command list to the breakpoint that prints the values of the arguments if the breakpoint is taken and continues execution.

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

    • Set a breakpoint at the exits from the procedure.

    • Add a command list to the breakpoint that prints the return value if the breakpoint is taken.

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

    • Set a breakpoint at the entry to the procedure.

    • Add a command list to the breakpoint that prints the values of global variables if the breakpoint is taken.

9.6.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 and relink for debugging with a high-level debugger.

  • You want a file containing all values the arguments take on during the execution of the program.

9.6.8 Language specifics

  • C++: Also include class data members.

  • Java: For global variables, substitute class data members.

  • C: Use the varargs.h header file to access the arguments of functions with varying numbers of arguments.

  • Fortran: Create separate PRINT statements for each ENTRY.




Debugging by Thinking. A Multidisciplinary Approach
Debugging by Thinking: A Multidisciplinary Approach (HP Technologies)
ISBN: 1555583075
EAN: 2147483647
Year: 2002
Pages: 172

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net