To determine why a problem is happening, you usually want to execute your program up to or just before the point at which you observe the first evidence of the problem. Then you can examine the internal state of your program and try to identify something that explains the visible problem. Possibly you will see right away how the problem occurs, in which case you are finished debugging. You then correct your program, recompile, relink, and confirm that the correction works as intended.
Often, you will see something about the program state that is wrong but you will not see how it got that way. In that case, you need to make a guess at where the mistake might have occurred. Then, repeat this whole process, trying to stop at or just before the possible trouble point.
For simple problems, it may be easy to describe the conditions under which you want to stop the program; for example, "the first time traverse is called" or "when division_by_zero occurs". Other situations may require either more complex descriptions or repeated trial-and-error attempts to discover the critical information needed to solve your problem.
Breakpoints provide the means by which you specify to the debugger an event or condition under which you want to intervene in the execution of your program and what actions you want the debugger to take when that event is detected.
You can define breakpoints based on:
You can also enable, disable, or delete breakpoints.
Breakpoint commands include the following:
breakpoint_command
: breakpoint_definition_command
| obsolete_breakpoint_definition_command
In this section, you will find information on