Using gdb and valgrind

The two programs, and , are fabulous tools to find errors in your code. The standard gnu debugger is , very powerfull, virtually every debugger in is -based. So, you need to learn some . Another invaluable tool is . It allows you to track memory usage, stopping the program whenever an invalid operation has been made.

Both and can be used together, so that you can actually debug the program that is beeing analysed. This is possible due to a feature that makes it possible to attach any running process to a session.

The first step is to setup valgrind, but first, some interesting links about :

• Home page:
• Documentation: http://developer.kde.org/~sewardj/docs-2.0.0/manual.html
• How To:
• FAQ:
• Nice article explaining how to use:

[]

Running

---

I personaly use the following call:

valgrind -v --tool=memcheck --leak-check=yes --gdb-attach=yes --num-callers=10 --suppressions=amule.sup --gen-suppressions=yes ~/programs/amule/amule-dev-cvs/src/amule --enable-stdin

This way, leak-check is enabled, and whenever a problem is detected, the user will be prompted for whether he wants to start at the current position. This is a great moment to see the beast exactly at the moment of falilure. The parameter --num-callers, which defaults to 4, is the number of backtrace lines that shows you, 4 is too little.

Finally, there is --gen-suppressions and --suppressions. Suppressions are a way that provides us so that we don't have to see every single problem that the program has. Eventually, other libraries your program is using, like X itself, will show memory usage problems, and will show them. So, on the first few runs of , we will have to build a suppression file, which is specified by --suppressions= and we tell to generate suppressions on screen. --gen-suppressions=yes will do this. Suppressions are a few lines that you may copy/paste in the suppressions file, all you have to do is give each suppression a name and that's it.

When set up that way, each time finds something wrong, it will show you a few lines describing the problem and then it will ask you if you want it to generate the suppressions. If you say yes, the suppression appears on the screen, and you can copy/paste it in the suppressions file, so that next time you run valgring this error is not reported.

Now, after prompting the user for printing the suppression, will prompt the user again whether or not he should start . If you say accept, will attach the running process and you will be debugging the program exactly at the point of the invalid operation.

[]

A few useful commands

---

bt

backtrace, shows the stack frames (subroutine calls) that lead to the position you are now in code.

bt full

shows every frame with the values of the local variables, usually too much verbose, only do this if you want to send the output to another person to analyse.

up/down number

e.g.: up 5: goes up 5 stack frames. By default, whenever you enter , you will be placed in frame number 0. With the aid of the source code of the program you should be able to select the subroutine where you want to inspect the variables.

frame number

goes straight to the selected frame.

info locals

prints the value of all local variables belonging to the current frame.

p variable

e.g.: p *cur_src. Prints the named variable. Usually C like syntax will be allowed here.

l

prints 10 lines of source code around the current line. A separate editor for source browsing is usualy better, but this can be a quick way to see the code.

help/help command

Do I need to explain that? :)

There are other commands, but usualy these described will suffice. It's worth mentioning that can be run with the core file, i.e., that big file that is produced after a crash. To do that, type

gdb program_path core_file_path

Also there are GUI front ends to that make it a little bit more friendly (like ). GUI front ends are great to inspect several different variables by clicking with the mouse. But learning to use from the console is by far the fastest way to do the job, not to mention that you can do it quickly in a remote terminal session.

Also note that practice makes it perfect, so the only way to realy learn how to do this is by doing it. You will see that you will quickly learn how to move around , in spite of its daunting console interface. Soon it will become your friend. :)

NOTE: is a separate project from , or any other project refered in this text, and is not related to any of them.