<?xml version="1.0"?>
<?xml-stylesheet type="text/css" href="http://test.amule.szerverem.hu/w/skins/common/feed.css?303"?>
<feed xmlns="http://www.w3.org/2005/Atom" xml:lang="en">
		<id>http://test.amule.szerverem.hu/w/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=209.131.62.113</id>
		<title>AMule Project FAQ - User contributions [en]</title>
		<link rel="self" type="application/atom+xml" href="http://test.amule.szerverem.hu/w/api.php?action=feedcontributions&amp;feedformat=atom&amp;user=209.131.62.113"/>
		<link rel="alternate" type="text/html" href="http://test.amule.szerverem.hu/wiki/Special:Contributions/209.131.62.113"/>
		<updated>2026-04-05T18:27:34Z</updated>
		<subtitle>User contributions</subtitle>
		<generator>MediaWiki 1.23.3</generator>

	<entry>
		<id>http://test.amule.szerverem.hu/wiki/Using_gdb_and_valgrind</id>
		<title>Using gdb and valgrind</title>
		<link rel="alternate" type="text/html" href="http://test.amule.szerverem.hu/wiki/Using_gdb_and_valgrind"/>
				<updated>2008-09-09T02:58:08Z</updated>
		
		<summary type="html">&lt;p&gt;209.131.62.113: /* Running [http://valgrind.kde.org valgrind] */&lt;/p&gt;
&lt;hr /&gt;
&lt;div&gt;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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
The first step is to setup '''valgrind''', but first, some interesting links about [http://valgrind.kde.org valgrind]:&lt;br /&gt;
&lt;br /&gt;
* Home page: http://valgrind.kde.org/&lt;br /&gt;
* Documentation: http://developer.kde.org/~sewardj/docs-2.0.0/manual.html&lt;br /&gt;
* How To: http://www.tldp.org/HOWTO/Valgrind-HOWTO/&lt;br /&gt;
* FAQ: http://valgrind.kde.org/faq.html&lt;br /&gt;
* Nice article explaining how to use: http://www.linux-mag.com/2003-05/compile_03.html&lt;br /&gt;
&lt;br /&gt;
== Running [http://valgrind.kde.org valgrind] ==&lt;br /&gt;
----&lt;br /&gt;
&lt;br /&gt;
I personaly use the following call:&lt;br /&gt;
&lt;br /&gt;
&amp;lt;code&amp;gt;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&amp;lt;/code&amp;gt;&lt;br /&gt;
&lt;br /&gt;
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. &lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
== A few [http://www.gnu.org/software/gdb/gdb.html gdb] useful commands ==&lt;br /&gt;
----&lt;br /&gt;
;'''''bt''''': backtrace, shows the stack frames (subroutine calls) that lead to the position you are now in code.&lt;br /&gt;
;'''''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.&lt;br /&gt;
;'''''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.&lt;br /&gt;
;'''''frame number''''': goes straight to the selected frame.&lt;br /&gt;
;'''''info locals''''': prints the value of all local variables belonging to the current frame.&lt;br /&gt;
;'''''p variable''''': e.g.: ''p *cur_src''. Prints the named variable. Usually C like syntax will be allowed here.&lt;br /&gt;
;'''''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.&lt;br /&gt;
;'''''help/help command''''': Do I need to explain that? :)&lt;br /&gt;
&lt;br /&gt;
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&lt;br /&gt;
&lt;br /&gt;
''gdb '''program_path''' '''core_file_path'''''&lt;br /&gt;
&lt;br /&gt;
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.&lt;br /&gt;
&lt;br /&gt;
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. :)&lt;br /&gt;
&lt;br /&gt;
'''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.&lt;/div&gt;</summary>
		<author><name>209.131.62.113</name></author>	</entry>

	</feed>