To debug is human. To fix it is divine...
Well, the human part is what this section is about. The divine part is up to you!
When a program does not behave in the way it is supposed to, we say the program contains a bug or bugs. This does not refer to compilation errors — those are simply errors and they are relatively easy to clear, because the compiler tells you where the problems are. On the other hand, bugs are errors that happen during the execution of the program and they can be hard (sometimes very hard!) to detect.
Any program that you think is bug-free is never completely bug-free. All we can try to do is to reduce the number of bugs contained in the program. The process of removing bugs is known as debugging, and the tool that is used for debugging is called the debugger. Anjuta provides a very user-friendly and powerful debugging environment (actually, a GUI wrapper over gdb, a powerful command line debugging tool).
A debugger tracks and traces the execution of the program and provides various views of information needed to study the execution of the program.
Before debugging, it is important to understand what debugging targets are. Debugging targets refer to those entities with which the debugger interacts during operation. There are four types of debugging targets:
There can be only one target active for each of the four types of targets at any give time. All of the targets do not need to be active for the debugger to work, although certain combinations are required active for a useful debugging session. Example combinations may be [ executable, symbol table, and process ] or [ executable, symbol table and core file ].
The target Executable becomes active when an executable file is loaded into the debugger.
The target Symbol table is automatically loaded from the executable file, therefore it does not have to be handled separately. The symbol table is necessary for the debugger to identify the various symbols in the source code of the program. The information is included in the executable during the compilation (as long as the program is compiled with the Debug option enabled — see the chapter called Setting Compiler Options> for details).
The target Core file becomes active when the core file is loaded into the debugger. A core file is the memory image of the program which was dumped by the kernel, usually because it had performed an illegal operation. The core file can provide information such as variable contents, register values, and stack trace of the program at the time of the error. By studying the core file it is possible to find out which part of the program has misbehaved and resulted in the core dump.
The target Process becomes active when the program is executed under the debugger or when you attach to an already running process.