Using gdb and valgrind
The two programs, gdb and valgrind, are fabulous tools to find errors in your code. The standard gnu debugger is gdb, very powerfull, virtually every debugger in GNU is gdb-based. So, you need to learn some gdb. Another invaluable tool is valgrind. It allows you to track memory usage, stopping the program whenever an invalid operation has been made.
Both valgrind and gdb can be used together, 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 --tool=memcheck --leak-check=yes --db-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.
Finally, 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 libraries 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. --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 valgrind 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, valgrind will prompt the user again whether or not he should start gdb. If you say accept, gdb will attach the running process and you will be debugging the program exactly at the point of the invalid operation.
A few gdb 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 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, 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 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 gdb, in spite of its daunting console interface. Soon it will become your friend. :)
NOTE: aMule is a separate project from gdb, valgrind or any other project refered in this text, and is not related to any of them.
