Debugging: Difference between revisions

Revision as of 12:21, 2 September 2024

Revision as of 16:40, 3 September 2024

Line 50:

==Techniques==

* ''Interactive debugging'' uses debugger tools which allow ana program's execution to be processed one step at a time and to be paused to inspect or alter its state. Subroutines or function calls may typically be executed at full speed and paused again upon return to their caller, or themselves single stepped, or any mixture of these options. Setpoints may be installed which permit full speed execution of code that is not suspected to be faulty, and then stop at a point that is. Putting a setpoint immediately after the end of a program loop is a convenient way to evaluate repeating code. Watchpoints are commonly available, where execution can proceed until a particular variable changes, and catchpoints which cause the debugger to stop for certain kinds of program events, such as exceptions or the loading of a shared library.

* ''{{visible anchor|Print debugging}}'' or ''[[Tracing (software)|tracing]]'' is the act of watching (live or recorded) trace statements, or print statements, that indicate the flow of execution of a process and the data progression. Tracing can be done with specialized tools (like with GDB's trace) or by insertion of trace statements into the source code. The latter is sometimes called ''{{visible anchor|printf debugging}}'', due to the use of the [[printf]] function in C. This kind of debugging was turned on by the command TRON in the original versions of the novice-oriented [[BASIC]] programming language. TRON stood for, "Trace On." TRON caused the line numbers of each BASIC command line to print as the program ran.

* ''Activity tracing'' is like tracing (above), but rather than following program execution one instruction or function at a time, follows program activity based on the overall amount of time spent by the processor/CPU executing particular segments of code. This is typically presented as a fraction of the program's execution time spent processing instructions within defined memory addresses (machine code programs) or certain program modules (high level language or compiled programs). If the program being debugged is shown to be spending an inordinate fraction of its execution time within traced areas, this could indicate misallocation of processor time caused by faulty program logic, or at least inefficient allocation of processor time that could benefit from optimization efforts.