9.7 Generate a flow trace


9.7 Generate a flow trace

9.7.1 Basic tactic

Run the application under an interpreter or high-level debugger, and generate a trace of all statements executed.

9.7.2 Purpose

Determine whether the code was ever executed.

9.7.3 Questions answered

  • What order were statements executed in?

  • What statements were and weren’t executed?

9.7.4 Potential problems

  • You can generate so much data that it becomes overwhelming.

  • If the problem is caused by stack or heap corruption, running under an interpreter or high-level debugger may cause the symptom to change or disappear because the stack and heap will be different.

9.7.5 Refined tactics

  1. Trace only selected statements.

  2. Trace only statements that control others—loop heads, conditional statements.

9.7.6 Related tactics

None.

9.7.7 Choosing tactics

Traces are only appropriate in a few situations:

  • The application is legitimately goto oriented. It could be a finite state machine or the output of another program.

  • The program is written in a very high-level language (VHLL) or in assembly language. In a VHLL, each statement has a high semantic content. In an assembly language, a simulator may be able to provide information not otherwise obtainable.




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

Similar book on Amazon

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