GDB

Introduction
GDB, or the (G)NU (D)e(B)ugger, is a program used to find run time errors that normally involve memory corruption. One of the main things you must do in order to debug a program is to the program with. This prevents the stripping of debug symbols. Why are programs stripped by default? The reason is the same as that for having gzipped man pages - saving space. Here's how the size of a program varies with and without debug symbol stripping.

Here, bad_code is the program we will debug with. The program without debugging symbols is 3140 bytes, while the program with them is 6374 bytes. Adding  to the system's CFLAGS and CXXFLAGS adds more debugging information than is generally included. This is how might look with the newly added flags.

You may also want to consider using  and   flags as well. prints compiler warnings, and  produces debugging information in the operating system's native format which also works with gdb. See GCC Debugging Options for details.

Lastly, add debug to the specific package's USE flags. This can be done with the file:

Then we re-emerge the package with the modifications we've done so far as shown below.

Now that debug symbols are set it is time to begin debugging the program.

If you need a little more help while debugging, such as being able to see the code within GDB TUI (GDB Text User Interface), install the package and include. You also need to specify the source code folder:

Although not really needed for meaningful backtraces, this significantly helps when actively coding.

Running the program with GDB
Let's say we have a program here called "bad_code". Some person claims that the program crashes and provides an example. You go ahead and test it out:

It seems this person was right. Since the program is obviously broken, there is now a bug at hand. Now, it is time to use to help solve this matter. First we run with the   option, then give it the full program with arguments like shown:

You should see a prompt that says "(gdb)" and waits for input. First, run the program with :

Here we see the program starting, as well as a notification of SIGSEGV, or Segmentation Fault. This is GDB telling us that the program has crashed. It also gives the last run function it could trace when the program crashes. However, this is not too useful, as there could be multiple strcpy's in the program, making it hard for developers to find which one is causing the issue. In order to help them out, we do what's called a backtrace. A backtrace runs backwards through all the functions that occurred upon program execution, to the function at fault. Functions that return (without causing a crash) will not show up on the backtrace. To get a backtrace at the (gdb) prompt type in. Something similar to the following message should be returned:

You can notice the trace pattern clearly. is called first, followed by, and somewhere in   lies the   at fault. Things such as this help developers narrow down problems. There are a few exceptions to the output. First off is forgetting to enable debug symbols with. With debug symbols stripped, the output looks something like this:

This backtrace contains a large number of  (question) marks. This is because without debug symbols, does not know how the program was run. Hence, it is crucial that debug symbols are not stripped. Let's see what the output looks like with   flag enabled:

Here we see that a lot more information is available for developers. Not only is function information displayed, but even the exact line numbers of the source files. This method is the most preferred if you can spare the extra space. Here's how much the file size varies between debug, strip, and  enabled programs.

As you can see,  adds about 13178 more bytes to the file size over the one with debugging symbols. However, as shown above, this increase in file size can be worth it if presenting debug information to developers. The backtrace can be saved to a file by copying and pasting from the terminal (if it's a non-x based terminal, you can use gpm. To keep this article simple, it is recommended users read up on GPM documentation to understand how to copy and paste with it). Now that we're done with, we can quit.

This ends the walk-through of. Using, we hope that you will be able to use it to create better bug reports. However, there are other types of errors that can cause a program to fail during run time. One of the other ways is through improper file access. We can find those using a nifty little tool called.