This document is intended to provide information on how to obtain the backtraces required on the asterisk bug tracker, available at https://issues.asterisk.org.
Overview
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.
If you start Asterisk with the safe_asterisk script, it automatically starts using the option -g.
If you're not sure if Asterisk is running with the -g option, type the following command in your shell:
# ps -C asterisk u USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 3018 1.1 2.7 636212 27768 pts/1 Sl+ 08:06 0:00 asterisk -vvvvvg -c [...]
The interesting information is located in the last column.
Second, your copy of Asterisk must have been built without optimization or the backtrace will be (nearly) unusable. This can be done by selecting the 'DONT_OPTIMIZE' option in the Compiler Flags submenu in the 'make menuselect' tree before building Asterisk. Running a production server with DONT_OPTIMIZE is generally safe. You'll notice the binary files may be a bit larger, but in terms of Asterisk performance, impact should be negligible.
Third, your copy of Asterisk must have the debug symbols still included in the binaries. This is the default unless you, or the package maintainer if installing from packages, strips the binaries. Normally a package maintainer will strip the binaries and then provide separate "debug" packages that contain just the symbols. If so, make sure those debug packages are installed.
After Asterisk crashes, a file named "core" will be dumped in the present working directory of the Linux shell from which Asterisk was started or in the location specified by the kernel.core_pattern sysctl setting. 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 Preliminary Information After A Crash
Before you go further, you must have the GNU Debugger (gdb) installed on the machine that experienced the crash. Use your package manager to install it if it isn't already.
ast_coredumper
Asterisk versions 13.14.0, 14.3.0, and later release branches added a few tools to make debugging easier. One of these is ast_coredumper. By default, it's installed in /var/lib/asterisk/scripts and it takes in a core file and produces backtraces and lock dumps in a format for uploading to Jira.
Running ast_coredumper for crashes
As you can see, there are lots of options but if the core file is simply named core in your current directory, running /var/lib/asterisk/scripts/ast_coredumper core will usually be sufficient.
Unless you've compiled Asterisk with the DEBUG_THREADS compiler flag (see below), the locks.txt file will be empty.
Many system administrators use the sysctl kernel.core_pattern parameter to control where core files are dumped and what they are named.
You'll notice that the output file names include the full core file name.
If the /etc/asterisk/ast_debug_tools.conf file contained a COREDUMPS entry that would have matched the core file name in /tmp, then you don't even have to supply a path.
By default, ast_coredumper also processes existing core files it detects. You can suppress that using the --no-default-search option and supplying a path directly to a coredump.
Running ast_coredumper for deadlocks, taskprocessor backups, etc.
When collecting information about a deadlock or taskprocessor backups, 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 steps below to collect debug that will be useful to Asterisk developers.
If you can easily reproduce the deadlock, in the Compiler Flags menu of menuselect you should enable DEBUG_THREADS, MALLOC_DEBUG, DONT_OPTIMIZE. Then, you need to recompile, re-install, and restart Asterisk before following the steps below. DEBUG_THREADS is very resource intensive and can seriously impact performance so you should only use it if you can reproduce the issue quickly. Otherwise, DONT_OPTIMIZE is the only option you really need.
When you suspect asterisk is deadlocked or you start seeing "task processor queue reached..." messages, you can use ast_coredumper to dump the currently running asterisk instance.
You can suppress the "continue" prompt by specifying --RUNNING instead of --running.
If Asterisk is truly deadlocked and you compiled with DEBUG_THREADS, the locks.txt file should now contain a table of locks including who's waiting and who's holding.
Reporting crashes and deadlocks
Subject to the warning above, you can attach the text files directly to an Asterisk issue. Occasionally, we'll ask you to run ast_coredumper again with additional options that will create a tarball that includes the Asterisk binaries and the the raw coredump. The command for that is /var/lib/asterisk/scripts/ast_coredumper --tarball-coredumps --no-default-search <path_to_coredump>. We'll give you instructions on how to get the file to us securely.
4 Comments
Ted G
errr...
gz/tmp# /var/lib/asterisk/scripts/ast_coredumper
OUTPUTDIR /some/directory doesn't exists or is not a directory
gz/tmp# /var/lib/asterisk/scripts/ast_coredumper /tmp/core
OUTPUTDIR /some/directory doesn't exists or is not a directory
gz/tmp# export OUTPUTDIR=/tmp ; echo $OUTPUTDIR
/tmp
gz/tmp# /var/lib/asterisk/scripts/ast_coredumper /tmp/core
OUTPUTDIR /some/directory doesn't exists or is not a directory
gz/tmp# asterisk -V
Asterisk 15.3.0
Looks like the problem is ast_debug_tools.conf is taking precedence over the environment setting.
[ -f /etc/asterisk/ast_debug_tools.conf ] && source /etc/asterisk/ast_debug_tools.conf
[ -f ~/ast_debug_tools.conf ] && source ~/ast_debug_tools.conf
[ -f ./ast_debug_tools.conf ] && source ./ast_debug_tools.conf
This doesn't seem like the appropriate behavior to me. The user should be able to change the output directory on the command line and not have to edit a config file every time. Also, it seems like /tmp should be the default directory instead of /some/directory which would probably never exist.
George Joseph
Hi Ted. can you open an issue for this at https://issues/asterisk.org? Thanks!
Ted G
Talha Omair
I think there should be note in section Getting Information After A Crash for those who installed asterisk on Ubuntu.
In Ubuntu, a file created in directory /var/crash. Everyone need to unpack this file using command
After that, in DestinationDirectory there will be Coredump file for further processing.