Difference between revisions of "Using gdb and valgrind"

Revision as of 03:26, 17 July 2004

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

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

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

• Home page: http://valgrind.kde.org/
• Documentation: http://developer.kde.org/~sewardj/docs-2.0.0/manual.html
• How To: http://www.tldp.org/HOWTO/Valgrind-HOWTO/
• FAQ: http://valgrind.kde.org/faq.html
• Nice article explaining how to use: http://www.linux-mag.com/2003-05/compile_03.html

Running Valgrind

I personaly use the following call:

valgrind -v --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 gdb 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 valgrind shows you, 4 is too little.

Finaly, there is --gen-suppressions and --suppressions. Suppressions are a way that valgrind provides us so that we don't have to see every single problem that the program has. Eventually, other libs your program is using, like X itself, will show memory usage problems, and valgrind will show them. So, on the first few runs of valgrind, we will have to build a suppression file, which is specified by --suppressions= and we tell valgrind to generate suppressions on screen with --gen-suppressions=yes. 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 valgrind finds something wrong, he will show you a few lines describing the problem and them he will ask you if you want him 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, valgrind will prompt the user again whether or not he should start gdb. If you say yes, gdb will attach the running process and you will be debugging the program exactly at the point of the invalid operation.

A few gdb usefull 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 gdb, 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 gdb can be run with the core file, i.e., that big file that is produced after a crash. To do that, you type

gdb program_path core_file_path.

Also there are gui front ends to gdb that make it a little bit more friendly (like kdbg). Gui front ends are great to inspect several different variables by clicking with the mouse. But learning to use gdb from the console is by far the quickiest 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 gdb, in spite of his daunting console interface. Soon he will become your friend. :)