|Table of Contents|
The backtrace information is required by developers to help fix problems with bugs of any kind. Backtraces provide information about what was wrong when a program crashed; in our case, Asterisk.
Preparing Asterisk To Produce Core Files On Crash
First of all, when you start Asterisk, you MUST start it with option -g. This tells Asterisk to produce a core file if it crashes.
In the event that there are multiple core files present, it is important to look at the file timestamps in order to determine which one you really intend to look at.
Getting Information After A Crash
There are two kind of backtraces (aka 'bt') which are useful: bt and bt full.
That output tells us crucial information about each thread.
Getting Information For A Deadlock
Whenever collecting information about a deadlock it is useful to have additional information about the threads involved. We can generate this information by attaching to a running Asterisk process and gathering that information. Follow the two steps below to collect debug that will be useful to Asterisk developers.
For more info on: Locking in Asterisk
Verify Your Backtraces
Before uploading your backtraces to the issue tracker, you should double check to make sure the data you have is of use to the developers.
Identifying Potential Memory Corruption
When you look at a backtrace, you'll usually see one of two things that indicate a memory corruption:
If you think there is a memory corruption issue then you'll want to run valgrind to investigate further.
Uploading Your Information To The Issue Tracker
You're now ready to upload your files to the Asterisk issue tracker (located at https://issues.asterisk.org).
Please ATTACH your output! DO NOT paste it as a note!
The menu item is located on the JIRA issue report under: ( More > Attach Files )
If you have questions or comments regarding this documentation, feel free to pass by the #asterisk-bugs channel on irc.freenode.net.