Difference between revisions of "Backtraces"

From AMule Project FAQ
Jump to: navigation, search
m (Removed HTML, Adjusted Links, Added Version-Tag)
m (Adjusted Links)
Line 3: Line 3:
  
 
Usually, it should not be necessary for the normal user to do this. However, we might have a bad day and release a somewhat buggy version or you are running [http://www.gnu.org/software/cvs CVS] which can also be unstable sometimes.
 
Usually, it should not be necessary for the normal user to do this. However, we might have a bad day and release a somewhat buggy version or you are running [http://www.gnu.org/software/cvs CVS] which can also be unstable sometimes.
This is where the backtraces come in: if [[AMule Project FAQ:About|aMule]] crashes, and you get an "OOPS - aMule crashed" and so on, we'd like to know. The backtrace [[AMule Project FAQ:About|aMule]] provides is not always very usefull as it contains little information, but, as usual, there's a better way: A *real* backtrace.
+
This is where the backtraces come in: if [[aMule]] crashes, and you get an "OOPS - aMule crashed" and so on, we'd like to know. The backtrace [[aMule]] provides is not always very usefull as it contains little information, but, as usual, there's a better way: A *real* backtrace.
  
 
== The GNU Debugger ==
 
== The GNU Debugger ==
Line 21: Line 21:
 
  # emerge -av gdb
 
  # emerge -av gdb
  
== Compiling [[AMule Project FAQ:About|aMule]] ==
+
== Compiling [[aMule]] ==
Then, compile [[AMule Project FAQ:About|aMule]] with debugging information:
+
Then, compile [[aMule]] with debugging information:
  
 
  $ ./configure --enable-debug --disable-optimize --prefix=/where/to/install/aMule
 
  $ ./configure --enable-debug --disable-optimize --prefix=/where/to/install/aMule
Line 28: Line 28:
 
  $ make install
 
  $ make install
  
If you do not want to overwrite you old copy of [[AMule Project FAQ:About|aMule]], simply do this instead:
+
If you do not want to overwrite you old copy of [[aMule]], simply do this instead:
  
 
  $ ./configure --enable-debug --disable-optimize
 
  $ ./configure --enable-debug --disable-optimize
 
  $ make
 
  $ make
  
[[AMule Project FAQ:About|aMule]] can then be run by going into the dir ''src'' and typing ''./amule''
+
[[aMule]] can then be run by going into the dir ''src'' and typing ''./amule''
  
 
If you are unable or unwilling to recompile, or are running a RPM version, proceed anyway, but be aware that backtraces from debugging enabled builds are much more useful to us.
 
If you are unable or unwilling to recompile, or are running a RPM version, proceed anyway, but be aware that backtraces from debugging enabled builds are much more useful to us.
Line 54: Line 54:
 
  (gdb) run
 
  (gdb) run
  
Now use [[AMule Project FAQ:About|aMule]] normally until it crashes. If it crashes do the following:
+
Now use [[aMule]] normally until it crashes. If it crashes do the following:
  
 
  (gdb) bt
 
  (gdb) bt
Line 60: Line 60:
 
  (gdb) thread apply all bt
 
  (gdb) thread apply all bt
  
Post the output of the last three commands in the [http://forum.amule.org/index.php?board=33.0 backtraces forum] with some additional comment about the circumstances the segfault happened and what [[AMule Project FAQ:About|aMule]] version you used (or checkout time for [http://www.gnu.org/software/cvs CVS]).
+
Post the output of the last three commands in the [http://forum.amule.org/index.php?board=33.0 backtraces forum] with some additional comment about the circumstances the segfault happened and what [[aMule]] version you used (or checkout time for [http://www.gnu.org/software/cvs CVS]).
  
 
== The core file ==
 
== The core file ==
If your [[AMule Project FAQ:About|aMule]] executable has been compiled with debug information (''--enable-debug'' configure flag), but you were not running it from within [http://www.gnu.org/software/gdb/gdb.html GDB], there is still a way to generate a backtrace, if your system was configured to generate '''core files'''.
+
If your [[aMule]] executable has been compiled with debug information (''--enable-debug'' configure flag), but you were not running it from within [http://www.gnu.org/software/gdb/gdb.html GDB], there is still a way to generate a backtrace, if your system was configured to generate '''core files'''.
  
 
Core files are the full memory image of a process that crashed. Your session must be properly configured, so that the system generates core files. Add the following command to ''~/.bashrc'':
 
Core files are the full memory image of a process that crashed. Your session must be properly configured, so that the system generates core files. Add the following command to ''~/.bashrc'':
Line 75: Line 75:
 
and then proceed as in the last session and issue 'bt' and 'bt full'.
 
and then proceed as in the last session and issue 'bt' and 'bt full'.
  
So, that's it, have fun with [[AMule Project FAQ:About|aMule]]
+
So, that's it, have fun with [[aMule]]
  
 
Greetings, [[User:Citroklar|Citroklar]] & [[User:Phoenix|Phoenix]]
 
Greetings, [[User:Citroklar|Citroklar]] & [[User:Phoenix|Phoenix]]
Line 88: Line 88:
 
== Version ==
 
== Version ==
 
Created by "Unknown User" on 28.04.04 at 23:21<br>
 
Created by "Unknown User" on 28.04.04 at 23:21<br>
Updated by Vollstrecker on 22.01.08 at 10:27
+
Updated by Vollstrecker on 22.01.08 at 12:06

Revision as of 12:05, 22 January 2008

Introduction

Well, not hard to guess, this is about backtraces.

Usually, it should not be necessary for the normal user to do this. However, we might have a bad day and release a somewhat buggy version or you are running CVS which can also be unstable sometimes. This is where the backtraces come in: if aMule crashes, and you get an "OOPS - aMule crashed" and so on, we'd like to know. The backtrace aMule provides is not always very usefull as it contains little information, but, as usual, there's a better way: A *real* backtrace.

The GNU Debugger

First of all, you need the GNU Debugger installed. It's called gdb and you could check for that by typing which gdb in a console window. You should see something like this:

$ which gdb
/usr/bin/gdb

If you don't have GDB installed, you will get a message like this:

$ which gdb
which: no gdb in (/bin:/usr/bin:[etc])

If that is the case, the GNU Debugger is most likely not installed on your system and you should install it before you proceed.

If your OS is Gentoo Linux you have just to type this:

# emerge -av gdb

Compiling aMule

Then, compile aMule with debugging information:

$ ./configure --enable-debug --disable-optimize --prefix=/where/to/install/aMule
$ make
$ make install

If you do not want to overwrite you old copy of aMule, simply do this instead:

$ ./configure --enable-debug --disable-optimize
$ make

aMule can then be run by going into the dir src and typing ./amule

If you are unable or unwilling to recompile, or are running a RPM version, proceed anyway, but be aware that backtraces from debugging enabled builds are much more useful to us.

Create a backtrace

Now create in your home directory the file .gdbinit and put these lines into it (or you can type them in at the (gdb) prompt later):

ha SIGPIPE nostop noprint pass
ha SIG32 nostop noprint pass
ha SIG33 nostop noprint pass
ha SIG34 nostop noprint pass

For those who want to know the meaning of the previous lines: the first one avoid GDB stopping at broken pipes; the second one avoid GDB stopping at new thread.

To create a backtrace, open a console and do the following:

$ gdb /where/to/install/aMule/bin/amule
(gdb) run

Now use aMule normally until it crashes. If it crashes do the following:

(gdb) bt
(gdb) bt full
(gdb) thread apply all bt

Post the output of the last three commands in the backtraces forum with some additional comment about the circumstances the segfault happened and what aMule version you used (or checkout time for CVS).

The core file

If your aMule executable has been compiled with debug information (--enable-debug configure flag), but you were not running it from within GDB, there is still a way to generate a backtrace, if your system was configured to generate core files.

Core files are the full memory image of a process that crashed. Your session must be properly configured, so that the system generates core files. Add the following command to ~/.bashrc:

ulimit -c unlimited

Now, when a program crashes, suppose it generate the file core.1234 (this name can be different, but usually will start with 'core') you can enter GDB like that:

$ gdb --core=/path/to/amule /path/to/core/file/core.1234

and then proceed as in the last session and issue 'bt' and 'bt full'.

So, that's it, have fun with aMule

Greetings, Citroklar & Phoenix

(Most of the above shamelessly stolen from pure_ascii's post in backtraces forum, thanks, pure!)

Please read this to learn more about GDB and Valgrind.

Links

Version

Created by "Unknown User" on 28.04.04 at 23:21
Updated by Vollstrecker on 22.01.08 at 12:06