Skip to end of metadata
Go to start of metadata

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.

Icon

Using BETTER_BACKTRACES

As of Asterisk versions 1.4.40, 1.6.2.17, and 1.8.3, the option BETTER_BACKTRACES which uses libbfd, will provide better symbol information within both the Asterisk binary, as well as loaded modules, to assist when using inline backtraces to track down problems. It is recommended that you enable both DONT_OPTIMIZE and BETTER_BACKTRACES. You do NOT need COMPILE_DOUBLE.

Icon

libbfd is included in the binutils-devel package on CentOS / RHEL, or the binutils-dev package on Debian / Ubuntu.

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.

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 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 and 14.3.0 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.  

/var/lib/asterisk/scripts/ast_coredumper --help  Expand source

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.

Finally, you might want to create a tarball of the text files and include the Jira issue id in the tarball name.


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 steps below to collect debug that will be useful to Asterisk developers.

In the Compiler Flags menu of menuselect you should enable DEBUG_THREADS, MALLOC_DEBUGDONT_OPTIMIZE and BETTER_BACKTRACES. Then, you need to recompile, re-install, and restart Asterisk before following the steps below.

Icon

Enabling DEBUG_THREADS can seriously impact performance and should only be enabled if you suspect a deadlock may be occurring.

MALLOC_DEBUG can also impact performance but the impact isn't nearly as severe.

When you suspect asterisk is deadlocked, you can use ast_coredumper again to dump the currently running asterisk instance.

By default, ast_coredumper also processes existing core files it detects.  You can suppress that using the --no-default-search option.  You can also suppress the warning and prompt using the --RUNNING option.

As above, you can also use the tarball options should you desire.

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.

 

 

  • No labels