Difference between revisions of "Using gdb and valgrind"

From AMule Project FAQ
Jump to: navigation, search
(valgrind options updated and suppression explanation clearified)
 
(29 intermediate revisions by 12 users not shown)
Line 1: Line 1:
The two programs, gdb and valgrind, are fabulous tools to find errors in your code. <b>gdb</b> is the standard gnu debugger, very powerfull, virtually every debugger in gnu is gdb based. So, you need to learn some gdb. <b>Valgrind</b> is another invaluable tool, that allows you to track memory usage, stopping the program whenever an invalid operation has been made.
+
The two programs, [http://www.gnu.org/software/gdb/gdb.html gdb] and [http://valgrind.kde.org valgrind], are fabulous tools to find errors in your code. The standard gnu debugger is [http://www.gnu.org/software/gdb/gdb.html gdb], very powerfull, virtually every debugger in [http://www.gnu.org GNU] is [http://www.gnu.org/software/gdb/gdb.html gdb]-based. So, you need to learn some [http://www.gnu.org/software/gdb/gdb.html gdb]. Another invaluable tool is [http://valgrind.kde.org valgrind]. It allows you to track memory usage, stopping the program whenever an invalid operation has been made.
  
<b>Valgrind</b> can be used together with <b>gdb</b>, so that you can actually debug the program that is beeing analised. This is possible due to a gdb feature that makes it possible to attach any running process to a gdb session.
+
Both [http://valgrind.kde.org valgrind] and [http://www.gnu.org/software/gdb/gdb.html gdb] can be used together, so that you can actually debug the program that is beeing analysed. This is possible due to a [http://www.gnu.org/software/gdb/gdb.html gdb] feature that makes it possible to attach any running process to a [http://www.gnu.org/software/gdb/gdb.html gdb] session.
  
The first step is to setup valgrind, but first, some interesting links about valgrind:
+
The first step is to setup '''valgrind''', but first, some interesting links about [http://valgrind.kde.org valgrind]:
  
* Home page: http://valgrind.kde.org/
+
* Home page: http://valgrind.org/
 
* Documentation: http://developer.kde.org/~sewardj/docs-2.0.0/manual.html
 
* Documentation: http://developer.kde.org/~sewardj/docs-2.0.0/manual.html
 
* How To: http://www.tldp.org/HOWTO/Valgrind-HOWTO/
 
* How To: http://www.tldp.org/HOWTO/Valgrind-HOWTO/
* FAQ: http://valgrind.kde.org/faq.html
+
* FAQ: http://valgrind.org/docs/manual/faq.html
* Nice article explaining how to use: http://www.linux-mag.com/2003-05/compile_03.html
+
 
 +
== Running [http://valgrind.kde.org valgrind] ==
 +
----
  
 
I personaly use the following call:
 
I personaly use the following call:
  
<code>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</code>
+
<code>valgrind -v --tool=memcheck --leak-check=yes --num-callers=10 --suppressions=amule.sup --gen-suppressions=yes ~/programs/amule/amule-dev-cvs/src/amule --enable-stdin</code>
  
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.  
+
This way, leak-check is enabled, and whenever a problem is detected, the user will be prompted for whether he wants to start [http://www.gnu.org/software/gdb/gdb.html 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 [http://valgrind.kde.org 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 <b>every</b> 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.
+
Finally, there is ''--gen-suppressions'' and ''--suppressions''. Suppressions are a way that [http://valgrind.kde.org 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 [http://valgrind.kde.org valgrind] will show them. So, on the first few runs of [http://valgrind.kde.org valgrind], we will have to build a suppression file, which is specified by ''--suppressions='' and we tell [http://valgrind.kde.org 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. So first run [http://valgrind.kde.org valgrind] with the ''--gensuppressions=yes'' option and copy the output to the desired file. On the next run add the ''--suppressions='' option instead.
  
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.
+
When set up that way, each time [http://valgrind.kde.org 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 yes, gdb will attach the running process and you will be debugging the program exactly at the point of the invalid operation.
+
Now, after prompting the user for printing the suppression, [http://valgrind.kde.org valgrind] will prompt the user again whether or not he should start [http://www.gnu.org/software/gdb/gdb.html gdb]. If you say accept, [http://www.gnu.org/software/gdb/gdb.html 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 are:
+
== A few [http://www.gnu.org/software/gdb/gdb.html 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 [http://www.gnu.org/software/gdb/gdb.html 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? :)
  
* bt: backtrace, shows the stack frames (subroutine calls) that lead to the position you are now in code.
+
There are other commands, but usualy these described will suffice. It's worth mentioning that [http://www.gnu.org/software/gdb/gdb.html gdb] can be run with the core file, i.e., that big file that is produced after a crash. To do that, type
* 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: ex.: up 5: goes up 5 stack frames. By default, whenever you enter gdb, you will be placed in frame number 0. <b>With the aid of the source code of the program</b> 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: ex.: 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.
+
  
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'''''
  
<code>gdb program_path core_file_path.</code>
+
Also there are GUI front ends to [http://www.gnu.org/software/gdb/gdb.html gdb] that make it a little bit more friendly (like [http://kgdb.sourceforge.net kdbg]). GUI front ends are great to inspect several different variables by clicking with the mouse. But learning to use [http://www.gnu.org/software/gdb/gdb.html 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 there are gui front ends to gdb that make it a little bit more friendly (like kdgb). 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 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 [http://www.gnu.org/software/gdb/gdb.html gdb], in spite of its daunting console interface. Soon it will become your friend. :)
  
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. :)
+
'''NOTE:''' [[aMule]] is a '''separate''' project from [http://www.gnu.org/software/gdb/gdb.html gdb], [http://valgrind.kde.org valgrind] or any other project refered in this text, and is '''not''' related to any of them.

Latest revision as of 20:31, 11 May 2009

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:

Running valgrind


I personaly use the following call:

valgrind -v --tool=memcheck --leak-check=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. So first run valgrind with the --gensuppressions=yes option and copy the output to the desired file. On the next run add the --suppressions= option instead.

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.