Typical Debugging Process
Normally the first step in debugging is to attempt to reproduce the problem. This can be a non-trivial task, for example as with parallel processes or some unusual software bugs. Also, specific user environment and usage history can make it difficult to reproduce the problem.
After the bug is reproduced, the input of the program may need to be simplified to make it easier to debug. For example, a bug in a compiler can make it crash when parsing some large source file. However, after simplification of the test case, only few lines from the original source file can be sufficient to reproduce the same crash. Such simplification can be made manually, using a divide-and-conquer approach. The programmer will try to remove some parts of original test case and check if the problem still exists. When debugging the problem in a GUI, the programmer can try to skip some user interaction from the original problem description and check if remaining actions are sufficient for bugs to appear.
After the test case is sufficiently simplified, a programmer can use a debugger tool to examine program states (values of variables, plus the call stack) and track down the origin of the problem(s). Alternatively, tracing can be used. In simple cases, tracing is just a few print statements, which output the values of variables at certain points of program execution.
Read more about this topic: Debugging
Famous quotes containing the words typical and/or process:
“New York is the meeting place of the peoples, the only city where you can hardly find a typical American.”
—Djuna Barnes (1892–1982)
“We tend to be so bombarded with information, and we move so quickly, that there’s a tendency to treat everything on the surface level and process things quickly. This is antithetical to the kind of openness and perception you have to have to be receptive to poetry. ... poetry seems to exist in a parallel universe outside daily life in America.”
—Rita Dove (b. 1952)