<html>
<head>
<base href="https://wiki.asterisk.org/wiki">
<link rel="stylesheet" href="/wiki/s/en/2176/25/9/_/styles/combined.css?spaceKey=AST&forWysiwyg=true" type="text/css">
</head>
<body style="background: white;" bgcolor="white" class="email-body">
<div id="pageContent">
<div id="notificationFormat">
<div class="wiki-content">
<div class="email">
<h2><a href="https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace">Getting a Backtrace</a></h2>
<h4>Page <b>edited</b> by <a href="https://wiki.asterisk.org/wiki/display/~rnewton">Rusty Newton</a>
</h4>
<div id="versionComment">
<b>Comment:</b>
Added a note about valgrind, MALLOC_DEBUG and mmlog<br />
</div>
<br/>
<h4>Changes (1)</h4>
<div id="page-diffs">
<table class="diff" cellpadding="0" cellspacing="0">
<tr><td class="diff-snipped" >...<br></td></tr>
<tr><td class="diff-unchanged" >2. An abort or seg fault in free. That's pretty much always a memory corruption. <br> <br></td></tr>
<tr><td class="diff-added-lines" style="background-color: #dfd;">If you think there is a memory corruption issue then you'll want to run [valgrind|https://wiki.asterisk.org/wiki/display/AST/Valgrind], and collect the /var/log/asterisk/mmlog (generated with the MALLOC_DEBUG compilation option). The output from those steps can then be provided to a developer for analysis. <br> <br></td></tr>
<tr><td class="diff-unchanged" >h2. Uploading Your Information To The Issue Tracker <br> <br></td></tr>
<tr><td class="diff-snipped" >...<br></td></tr>
</table>
</div> <h4>Full Content</h4>
<div class="notificationGreySide">
<p>This document is intended to provide information on how to obtain the backtraces required on the asterisk bug tracker, available at <a href="https://issues.asterisk.org" class="external-link" rel="nofollow">https://issues.asterisk.org</a>.</p>
<div>
<ul>
<li><a href='#GettingaBacktrace-Overview'>Overview</a></li>
<li><a href='#GettingaBacktrace-PreparingAsteriskToProduceCoreFilesOnCrash'>Preparing Asterisk To Produce Core Files On Crash</a></li>
<li><a href='#GettingaBacktrace-GettingInformationAfterACrash'>Getting Information After A Crash</a></li>
<li><a href='#GettingaBacktrace-GettingInformationForADeadlock'>Getting Information For A Deadlock</a></li>
<li><a href='#GettingaBacktrace-VerifyYourBacktraces'>Verify Your Backtraces</a></li>
<li><a href='#GettingaBacktrace-IdentifyingPotentialMemoryCorruption'>Identifying Potential Memory Corruption</a></li>
<li><a href='#GettingaBacktrace-UploadingYourInformationToTheIssueTracker'>Uploading Your Information To The Issue Tracker</a></li>
</ul></div>
<h2><a name="GettingaBacktrace-Overview"></a>Overview</h2>
<p>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.</p>
<h2><a name="GettingaBacktrace-PreparingAsteriskToProduceCoreFilesOnCrash"></a>Preparing Asterisk To Produce Core Files On Crash</h2>
<p>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.</p>
<p>If you start Asterisk with the safe_asterisk script, it automatically starts using the option -g.</p>
<p>If you're not sure if Asterisk is running with the -g option, type the following command in your shell:</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre># 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
[...]
</pre>
</div></div>
<p>The interesting information is located in the last column.</p>
<p>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.</p>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td><div class='table-wrap'>
<table class='confluenceTable'><tbody>
<tr>
<th class='confluenceTh'> Using BETTER_BACKTRACES </th>
</tr>
<tr>
<td class='confluenceTd'> 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. <b>It is recommended that you enable both DONT_OPTIMIZE and BETTER_BACKTRACES</b> </td>
</tr>
</tbody></table>
</div>
</td></tr></table></div>
<div class='panelMacro'><table class='tipMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/check.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>libbfd is included in the binutils-devel package on CentOS / RHEL, or the binutils-dev package on Debian / Ubuntu.</td></tr></table></div>
<p>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.</p>
<p>After Asterisk crashes, a file named "core" will be dumped in the present working directory of the Linux shell from which Asterisk was started.</p>
<p>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.</p>
<h2><a name="GettingaBacktrace-GettingInformationAfterACrash"></a>Getting Information After A Crash</h2>
<p>There are two kind of backtraces (aka 'bt') which are useful: bt and bt full.</p>
<p>Now that we've verified the core file has been written to disk, the final part is to extract 'bt' from the core file. Core files are pretty big, don't be scared, it's normal.</p>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>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 the 'bt' and 'bt full.'</td></tr></table></div>
<p>For extraction, we use a really nice tool, called gdb. To verify that you have gdb installed on your system:</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre># gdb -v
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i486-linux-gnu"...
</pre>
</div></div>
<p>If you don't have gdb installed, go install gdb. You should be able to install using something like: apt-get install gdb -<del>or</del>- yum install gdb</p>
<div class='panelMacro'><table class='tipMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/check.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>Just run the following command to get the output into the backtrace.txt file, ready for uploading to the issue tracker. Be sure to change the name of the core file to your actual core dump file:</td></tr></table></div>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre># gdb -se "asterisk" -ex "bt full" -ex "thread apply all bt" --batch -c core > /tmp/backtrace.txt
</pre>
</div></div>
<p>Now load the core file in gdb with the following command. This will also save the output of gdb to the /tmp/backtract.txt file.</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre># gdb -se "asterisk" -c core | tee /tmp/backtrace.txt
[...]
(You would see a lot of output here.)
[...]
Reading symbols from /usr/lib/asterisk/modules/app_externalivr.so...done.
Loaded symbols for /usr/lib/asterisk/modules/app_externalivr.so
#0 0x29b45d7e in ?? ()
(gdb)
</pre>
</div></div>
<p>In order to make extracting the gdb output easier, you may wish to turn on logging using "set logging on". This command will save all output to the default file of gdb.txt, which in the end can be uploaded as an attachment to the bug tracker.</p>
<p>Now at the gdb prompt, type: bt You would see output similar to:</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>(gdb) bt
#0 0x29b45d7e in ?? ()
#1 0x08180bf8 in ?? ()
#2 0xbcdffa58 in ?? ()
#3 0x08180bf8 in ?? ()
#4 0xbcdffa60 in ?? ()
#5 0x08180bf8 in ?? ()
#6 0x180bf894 in ?? ()
#7 0x0bf80008 in ?? ()
#8 0x180b0818 in ?? ()
#9 0x08068008 in ast_stopstream (tmp=0x40758d38) at file.c:180
#10 0x000000a0 in ?? ()
#11 0x000000a0 in ?? ()
#12 0x00000000 in ?? ()
#13 0x407513c3 in confcall_careful_stream (conf=0x8180bf8, filename=0x8181de8 "DAHDI/pseudo-1324221520") at app_meetme.c:262
#14 0x40751332 in streamconfthread (args=0x8180bf8) at app_meetme.c:1965
#15 0xbcdffbe0 in ?? ()
#16 0x40028e51 in pthread_start_thread () from /lib/libpthread.so.0
#17 0x401ec92a in clone () from /lib/libc.so.6
(gdb)
</pre>
</div></div>
<p>The bt's output is the information that we need on the bug tracker.</p>
<p>Now do a bt full as follows:</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>(gdb) bt full
#0 0x29b45d7e in ?? ()
No symbol table info available.
#1 0x08180bf8 in ?? ()
No symbol table info available.
#2 0xbcdffa58 in ?? ()
No symbol table info available.
#3 0x08180bf8 in ?? ()
No symbol table info available.
#4 0xbcdffa60 in ?? ()
No symbol table info available.
#5 0x08180bf8 in ?? ()
No symbol table info available.
#6 0x180bf894 in ?? ()
No symbol table info available.
#7 0x0bf80008 in ?? ()
No symbol table info available.
#8 0x180b0818 in ?? ()
No symbol table info available.
#9 0x08068008 in ast_stopstream (tmp=0x40758d38) at file.c:180
No locals.
#10 0x000000a0 in ?? ()
No symbol table info available.
#11 0x000000a0 in ?? ()
No symbol table info available.
#12 0x00000000 in ?? ()
No symbol table info available.
#13 0x407513c3 in confcall_careful_stream (conf=0x8180bf8, filename=0x8181de8 "DAHDI/pseudo-1324221520") at app_meetme.c:262
f = (struct ast_frame *) 0x8180bf8
trans = (struct ast_trans_pvt *) 0x0
#14 0x40751332 in streamconfthread (args=0x8180bf8) at app_meetme.c:1965
No locals.
#15 0xbcdffbe0 in ?? ()
No symbol table info available.
#16 0x40028e51 in pthread_start_thread () from /lib/libpthread.so.0
No symbol table info available.
#17 0x401ec92a in clone () from /lib/libc.so.6
No symbol table info available.
(gdb)
</pre>
</div></div>
<p>The final "extraction" would be to know all traces by all threads. Even if Asterisk runs on the same thread for each call, it could have created some new threads.</p>
<p>To make sure we have the correct information, just do:</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre>(gdb) thread apply all bt
Thread 1 (process 26252):
#0 0x29b45d7e in ?? ()
#1 0x08180bf8 in ?? ()
#2 0xbcdffa58 in ?? ()
#3 0x08180bf8 in ?? ()
#4 0xbcdffa60 in ?? ()
#5 0x08180bf8 in ?? ()
#6 0x180bf894 in ?? ()
#7 0x0bf80008 in ?? ()
#8 0x180b0818 in ?? ()
#9 0x08068008 in ast_stopstream (tmp=0x40758d38) at file.c:180
#10 0x000000a0 in ?? ()
#11 0x000000a0 in ?? ()
#12 0x00000000 in ?? ()
#13 0x407513c3 in confcall_careful_stream (conf=0x8180bf8, filename=0x8181de8 "DAHDI/pseudo-1324221520") at app_meetme.c:262
#14 0x40751332 in streamconfthread (args=0x8180bf8) at app_meetme.c:1965
#15 0xbcdffbe0 in ?? ()
#16 0x40028e51 in pthread_start_thread () from /lib/libpthread.so.0
#17 0x401ec92a in clone () from /lib/libc.so.6
(gdb)
</pre>
</div></div>
<p>That output tells us crucial information about each thread.</p>
<h2><a name="GettingaBacktrace-GettingInformationForADeadlock"></a>Getting Information For A Deadlock</h2>
<p>Whenever supplying information about a deadlock (i.e. when you run the 'core show locks' command on the Asterisk console), it is useful to also have additional information about the threads. We can generate this information by attaching to a running Asterisk process and gathering that information.</p>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>You need <b>DEBUG_THREADS</b> enabled in the Compiler Flags menu of menuselect. Be sure you recompile, install, and restart Asterisk prior to running 'core show locks'.</td></tr></table></div>
<p>You can easily attach to a running Asterisk process, gather the output required and then detach from the process all in a single step. Execute the following command and upload the resulting backtrace-threads.txt file to the Asterisk issue tracker:</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre># gdb -ex "thread apply all bt" --batch /usr/sbin/asterisk `pidof asterisk` > /tmp/backtrace-threads.txt
</pre>
</div></div>
<p>Note that this gathers information from the running Asterisk process, so you want to make sure you run this command immediately before or after gathering the output of 'core show locks'. You can gather that information by running the following command:</p>
<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">
<pre># asterisk -rx "core show locks" > /tmp/core-show-locks.txt
</pre>
</div></div>
<h2><a name="GettingaBacktrace-VerifyYourBacktraces"></a>Verify Your Backtraces</h2>
<p>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. Check your backtrace files to make sure you're not seeing several of the following:</p>
<div class="code panel" style="border-width: 1px;"><div class="codeContent panelContent">
<pre class="theme: Confluence; brush: java; gutter: false"><value optimized out></pre>
</div></div>
<p>If you are, then you likely haven't compiled with DONT_OPTIMIZE. The impact of DONT_OPTIMIZE is negligible on most systems. Be sure you've enabled the DONT_OPTIMIZE flag within the Compiler Flags section of menuselect. After doing so, be sure to run 'make install' and restart Asterisk.</p>
<div class='panelMacro'><table class='warningMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/forbidden.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>Double check your backtrace! It is important you do not see <value optimized out>, otherwise the backtrace does not provide enough information for a developer.</td></tr></table></div>
<h2><a name="GettingaBacktrace-IdentifyingPotentialMemoryCorruption"></a>Identifying Potential Memory Corruption</h2>
<p>When you look at a backtrace, you'll usually see one of two things that indicate a memory corruption:</p>
<p>1. A seg fault or an abort in malloc, calloc, or realloc. This could also be an indication that someone ran out of memory, but usually Asterisk "gracefully" handles that condition (although the system will more then likely tank pretty quickly, you'll get some ERROR messages). In general, a seg fault or abort in one of those three is very likely to be a memory corruption.</p>
<p>2. An abort or seg fault in free. That's pretty much always a memory corruption.</p>
<p>If you think there is a memory corruption issue then you'll want to run <a href="https://wiki.asterisk.org/wiki/display/AST/Valgrind" class="external-link" rel="nofollow">valgrind</a>, and collect the /var/log/asterisk/mmlog (generated with the MALLOC_DEBUG compilation option). The output from those steps can then be provided to a developer for analysis.</p>
<h2><a name="GettingaBacktrace-UploadingYourInformationToTheIssueTracker"></a>Uploading Your Information To The Issue Tracker</h2>
<p>You're now ready to upload your files to the Asterisk issue tracker (located at<a href="https://issues.asterisk.org" class="external-link" rel="nofollow">https://issues.asterisk.org</a>).</p>
<div class='panelMacro'><table class='noteMacro'><colgroup><col width='24'><col></colgroup><tr><td valign='top'><img src="/wiki/images/icons/emoticons/warning.gif" width="16" height="16" align="absmiddle" alt="" border="0"></td><td>Please ATTACH your output! DO NOT paste it as a note!</td></tr></table></div>
<p>If you have questions or comments regarding this documentation, feel free to pass by the #asterisk-bugs channel on irc.freenode.net.</p>
</div>
<div id="commentsSection" class="wiki-content pageSection">
<div style="float: right;" class="grey">
<a href="https://wiki.asterisk.org/wiki/users/removespacenotification.action?spaceKey=AST">Stop watching space</a>
<span style="padding: 0px 5px;">|</span>
<a href="https://wiki.asterisk.org/wiki/users/editmyemailsettings.action">Change email notification preferences</a>
</div>
<a href="https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace">View Online</a>
|
<a href="https://wiki.asterisk.org/wiki/pages/diffpagesbyversion.action?pageId=5243139&revisedVersion=14&originalVersion=13">View Changes</a>
|
<a href="https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace?showComments=true&showCommentArea=true#addcomment">Add Comment</a>
</div>
</div>
</div>
</div>
</div>
</body>
</html>