aMule Forum

Please login or register.

Login with username, password and session length
Advanced search  

News:

We're back! (IN POG FORM)

Author Topic: How to post a useful Backtrace  (Read 6844 times)

lionel77

  • Provider of Mac builds, Forum Mod
  • Hero Member
  • *****
  • Karma: 4
  • Offline Offline
  • Posts: 1107
  • Mac OS X 10.4 (Power Mac G5)
How to post a useful Backtrace
« on: October 12, 2005, 03:00:26 AM »

You experience occasional crashes with aMule and would like to help us fix them? Then this thread is for you. :)

The following instructions will tell you how to generate a so-called backtrace in the case of a crash. These backtraces will allow us to identify the nature of the crash and fix its underlying cause. The instructions are relatively detailed so that even less tech-savvy Mac users should have no problems following them.


(1) Install/Update the Developer Tools
First, make sure that you have the most recent version of Apple's Developer Tools installed. You can download them from the Apple Developer page, after you have created a free ADC account (if you don't have one already).
Go to "Downloads" -> "Developer Tools".
Panther users: Please download and install "Xcode Tools v1.5" and the "November 2004 GCC 3.3 Updater" (in this order).
Tiger users: Please download and install "Xcode Tools 2.1".


(2) Create the .gdbinit file
Eventually, we will run aMule through the gdb debugger. In this step we create an (invisible) .gdbinit file in your home folder that prevents gdb to stop at certain non-critical events. This file has to be created only once.
  • Open Applications -> Utilities -> Terminal.
  • Copy the following line to the command line and hit return:
echo "handle SIGPIPE nostop noprint pass" > ~/.gdbinit
  • Then do the same with the following line:
echo "handle SIG32 nostop noprint pass" >> ~/.gdbinit
[/list]

(3) Get an aMule version that contains debug information
The easiest way is to grab one of my builds from this thread. Just make sure you are downloading the debug version.
If you are an advanced user and prefer to compile aMule yourself, make sure you compile wxWidgets with "--enable-debug" & "--enable-debug_gdb" and aMule with "--enable-debug".


(4) Run aMule through the gdb debugger
Now comes the interesting part, we are going to run aMule in the debug environment. If aMule is still running please quit it now. Then:
  • Go to a Terminal window (see (2) above).
  • At the command line, type "gdb" and a space, but don't press return yet.
  • Now, drag the aMule application icon from wherever you keep it and drop it onto the terminal window. Terminal will insert the path to the application onto the command line. It will also add a space after the path.
  • Delete the space at the end of the path.
  • Add "/Contents/MacOS/amule" to the end of the path and press return.

gdb will start up, load some symbols, and then present the prompt "(gdb) ".
  • Type "run" and press return.

aMule will then start as if you had just double-clicked it in the Finder, but in addition it will also spit out some more information in the Terminal window.
  • Use aMule as normal until it crashes. In the GUI, this will be evident when it stops responding completely and you are getting the spinning beachball cursor.
  • Switch back to the terminal. There should be some messages about the nature of the crash, something like "/usr/include/gcc/darwin/3.3/c++/debug/safe_iterator.h:373:error: attempt to compare a singular iterator to a singular iterator. [...]", "Program received signal SIGABRT, Aborted." or so. This is the first output that you will report later. If you are unclear about where the crash related message starts you can be a bit generous here.
  • You will also get a "(gdb) " prompt again. Now type "bt" and return to generate a regular backtrace. Then type "bt full" and hit return to generate a more complete backtrace. Finally, type "thread apply all bt" and hit return.
  • To quit gdb, type "quit" and hit return.
Congratulations, you now have all the information you need to report a useful backtrace on the aMule forum.


(5) Reporting the backtrace on the forum
There is a dedicated "Backtraces" sub-forum on the aMule forum, this is where you usually want to post your backtraces.
  • So start a new thread in the Backtraces forum.
  • Put the aMule version at the beginning of the title. You can either use the date (e.g., "2005-10-15") or the CVS rev number (e.g., "rev 5448"). Also, if amule crashed while you were doing something in it, include what you did (e.g., "when canceling a download"). Otherwise include part of the crash message (e.g., "EXC_BAD_ACCESS, Could not access memory".
  • At the beginning of the post, write a quick description, under which circumstances the crash occurred (e.g., "I tried to cancel a download", "amule was just running in the background", etc.).
  • Now copy everything from the beginning of the crash message to the end of the output from "thread apply all bt" into the post. I highly recommend using the "Insert CODE" button (the one with the "#") for this purpose, because this way, the formatting is preserved. If you want to post a very clean backtrace, you can insert each part (i.e. crash message, output from "bt",  output from "bt full", and  output from "thread apply all bt") separately with the "Insert CODE" button.
  • Hit "Submit".
That's it -- you just posted your first backtrace. :)
Logged
Current aMule CVS builds for OS X can be found here.