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.
Don't attach core files on the bug tracker as they are only useful on the machine they were generated on. We only need the output of ast_coredumper.
Asterisk versions 13.14.0 and , 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.
NAME ast_coredumper - Dump and/or format asterisk coredump files SYNOPSIS ast_coredumper [ --help ] [ --running | --RUNNING ] [ --latest ] [ --tarball-coredumps ] [ --delete-coredumps-after ] [ --tarball-results ] [ --delete-results-after ] [ --tarball-uniqueid="<uniqueid>" ] [ --no-default-search ] [ --append-coredumps ] [ <coredump> | <pattern> ... ] DESCRIPTION Extracts backtraces and lock tables from Asterisk coredump files. For each coredump found, 4 new result files are created: - <coredump>.brief.txt: The output of "thread apply all bt". - <coredump>.thread1.txt: The output of "thread apply 1 bt full". - <coredump>.full.txt: The output of "thread apply all bt full". - <coredump>.locks.txt: If asterisk was compiled with "DEBUG_THREADS", this file will contain a dump of the locks table similar to doing a "core show locks" from the asterisk CLI. Optional features: - The running asterisk process can be suspended and dumped. - The coredumps can be merged into a tarball. - The coredumps can be deleted after processing. - The results files can be merged into a tarball. - The results files can be deleted after processing. Options: --help Print this help. --running Create a coredump from the running asterisk instance and process it along with any other coredumps found (if any). WARNING: This WILL interrupt call processing. You will be asked to confirm. --RUNNING Same as --running but without the confirmation prompt. DANGEROUS!! --latest Process only the latest coredump from those specified (based on last-modified time). If a dump of the running process was requested, it is always included in addition to the latest from the existing coredumps. --tarball-coredumps Creates a gzipped tarball of all coredumps processed. The tarball name will be: /tmp/asterisk.<timestamp>.coredumps.tar.gz --delete-coredumps-after Deletes all processed coredumps regardless of whether a tarball was created. --tarball-results Creates a gzipped tarball of all result files produced. The tarball name will be: /tmp/asterisk.<timestamp>.results.tar.gz --delete-results-after Deletes all processed results regardless of whether a tarball was created. It probably doesn't make sense to use this option unless you have also specified --tarball-results. --tarball-uniqueid="<uniqueid>" Normally DATEFORMAT is used to make the tarballs unique but you can use your own unique id in the tarball names such as the Jira issue id. --no-default-search Ignore COREDUMPS from the config files and process only coredumps listed on the command line (if any) and/or the running asterisk instance (if requested). --append-coredumps Append any coredumps specified on the command line to the config file specified ones instead of overriding them. <coredump> | <pattern> A list of coredumps or coredump search patterns. Unless --append-coredumps was specified, these entries will override those specified in the config files. Any resulting file that isn't actually a coredump is silently ignored. If your patterns contains spaces be sure to only quote the portion of the pattern that DOESN'T contain wildcard expressions. If you quote the whole pattern, it won't be expanded. If --no-default-search is specified and no files are specified on the command line, then the only the running asterisk process will be dumped (if requested). Otherwise if no files are specified on the command line the value of COREDUMPS from ast_debug_tools.conf will be used. Failing that, the following patterns will be used: /tmp/core[-._]asterisk!(*.txt) /tmp/core[-._]$(hostname)!(*.txt) NOTES You must be root to use ast_coredumper. The script relies on not only bash, but also recent GNU date and gdb with python support. *BSD operating systems may require installation of the 'coreutils' and 'devel/gdb' packagess and minor tweaking of the ast_debug_tools.conf file. Any files output will have ':' characters changed to '-'. This is to facilitate uploading those files to Jira which doesn't like the colons. FILES /etc/asterisk/ast_debug_tools.conf ~/ast_debug_tools.conf ./ast_debug_tools.conf # # This file is used by the Asterisk debug tools. # Unlike other Asterisk config files, this one is # "sourced" by bash and must adhere to bash semantics. # # A list of coredumps and/or coredump search patterns. # Bash extended globs are enabled and any resulting files # that aren't actually coredumps are silently ignored # so you can be liberal with the globs. # # If your patterns contains spaces be sure to only quote # the portion of the pattern that DOESN'T contain wildcard # expressions. If you quote the whole pattern, it won't # be expanded and the glob characters will be treated as # literals. # # The exclusion of files ending ".txt" is just for # demonstration purposes as non-coredumps will be ignored # anyway. COREDUMPS=(/tmp/core[-._]asterisk!(*.txt) /tmp/core[-._]$(hostname)!(*.txt)) # Date command for the "running" coredump and tarballs. # DATEFORMAT will be executed to get the timestamp. # Don't put quotes around the format string or they'll be # treated as literal characters. Also be aware of colons # in the output as you can't upload files with colons in # the name to Jira. # # Unix timestamp #DATEFORMAT='date +%s.%N' # # *BSD/MacOS doesn't support %N but after installing GNU # coreutils... #DATEFORMAT='gdate +%s.%N' # # Readable GMT #DATEFORMAT='date -u +%FT%H-%M-%S%z' # # Readable Local time DATEFORMAT='date +%FT%H-%M-%S%z'
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.
$ sudo /var/lib/asterisk/scripts/ast_coredumper core Processing core Creating core-thread1.txt Creating core-brief.txt Creating core-full.txt Creating core-locks.txt $
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.
$ sysctl -n kernel.core_pattern /tmp/core-%e-%t $ ls -al /tmp/core-asterisk* -rw-------. 1 root root 173936640 Jun 16 07:44 /tmp/core-asterisk-1497620664.32259 $ sudo /var/lib/asterisk/scripts/ast_coredumper /tmp/core-asterisk-1497620664.32259 Processing /tmp/core-asterisk-1497620664.32259 Creating /tmp/core-asterisk-1497620664.32259-thread1.txt Creating /tmp/core-asterisk-1497620664.32259-brief.txt Creating /tmp/core-asterisk-1497620664.32259-full.txt Creating /tmp/core-asterisk-1497620664.32259-locks.txt
You'll notice that the output file names include the full core file name.
/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.
$ sudo /var/lib/asterisk/scripts/ast_coredumper Processing /tmp/core-asterisk-1497620664.32259 Creating /tmp/core-asterisk-1497620664.32259-thread1.txt Creating /tmp/core-asterisk-1497620664.32259-brief.txt Creating /tmp/core-asterisk-1497620664.32259-full.txt Creating /tmp/core-asterisk-1497620664.32259-locks.txt
Finally, you might want to create a tarball of the text files and include the Jira issue id in the tarball name.
$ sudo /var/lib/asterisk/scripts/ast_coredumper --tarball-uniqueid=ASTERISK-99999 --tarball-results Processing /tmp/core-asterisk-1497620664.32259 Creating /tmp/core-asterisk-1497620664.32259-thread1.txt Creating /tmp/core-asterisk-1497620664.32259-brief.txt Creating /tmp/core-asterisk-1497620664.32259-full.txt Creating /tmp/core-asterisk-1497620664.32259-locks.txt Creating /tmp/asterisk-ASTERISK-99999-results.tar.gz /tmp/core-asterisk-1497620664.32259-brief.txt /tmp/core-asterisk-1497620664.32259-full.txt /tmp/core-asterisk-1497620664.32259-thread1.txt /tmp/core-asterisk-1497620664.32259-locks.txt
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_DEBUG, DONT_OPTIMIZE and BETTER_BACKTRACES. Then, you need to recompile, re-install, and restart Asterisk before following the steps below.
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 is not very noticeable.
When you suspect asterisk is deadlocked, you can use ast_coredumper again to dump the currently running asterisk instance.
$ sudo /var/lib/asterisk/scripts/ast_coredumper --running WARNING: Taking a core dump of the running asterisk instance will suspend call processing while the dump is saved. Do you wish to continue? (y/N) y Dumping running asterisk process to /tmp/core-asterisk-running-2017-06-16T09-56-53-0600 Processing /tmp/core-asterisk-1497620664.32259 Creating /tmp/core-asterisk-1497620664.32259-thread1.txt Creating /tmp/core-asterisk-1497620664.32259-brief.txt Creating /tmp/core-asterisk-1497620664.32259-full.txt Creating /tmp/core-asterisk-1497620664.32259-locks.txt Processing /tmp/core-asterisk-running-2017-06-16T09-56-53-0600 Creating /tmp/core-asterisk-running-2017-06-16T09-56-53-0600-thread1.txt Creating /tmp/core-asterisk-running-2017-06-16T09-56-53-0600-brief.txt Creating /tmp/core-asterisk-running-2017-06-16T09-56-53-0600-full.txt Creating /tmp/core-asterisk-running-2017-06-16T09-56-53-0600-locks.txt
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
$ sudo /var/lib/asterisk/scripts/ast_coredumper --RUNNING --no-default-search Dumping running asterisk process to /tmp/core-asterisk-running-2017-06-16T10-00-03-0600 Processing /tmp/core-asterisk-running-2017-06-16T10-00-03-0600 Creating /tmp/core-asterisk-running-2017-06-16T10-00-03-0600-thread1.txt Creating /tmp/core-asterisk-running-2017-06-16T10-00-03-0600-brief.txt Creating /tmp/core-asterisk-running-2017-06-16T10-00-03-0600-full.txt Creating /tmp/core-asterisk-running-2017-06-16T10-00-03-0600-locks.txt
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.