<html>

<head>

    <base href="https://wiki.asterisk.org/wiki">

            <link rel="stylesheet" href="/wiki/s/2030/1/7/_/styles/combined.css?spaceKey=AST&amp;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/~mmichelson">Mark Michelson</a>

    </h4>

        <div id="versionComment">

        <b>Comment:</b>

        Adding a note that core dumps are not always in /tmp and that they may be in the directory from which Asterisk was run.<br />

    </div>

        <br/>

                         <h4>Changes (2)</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" >Running a production server with DONT_OPTIMIZE is generally safe. You&#39;ll notice the binary files may be a bit larger, but in terms of Asterisk performance, and impact should be negligible. <br> <br></td></tr>

            <tr><td class="diff-deleted-lines" style="color:#999;background-color:#fdd;text-decoration:line-through;">After Asterisk crashes, a core file will be &quot;dumped&quot; in your /tmp/ directory. To make sure it&#39;s really there, you can just type the following command in your shell: <br></td></tr>

            <tr><td class="diff-added-lines" style="background-color: #dfd;">After Asterisk crashes, a core file will be &quot;dumped.&quot; The most likely location for the core dump will be in your /tmp/ directory or the directory from which you started Asterisk. For the following examples, we are assuming that /tmp is the location in which your core files are dumped. To make sure the core dump is really there, you can just type the following command in your shell: <br></td></tr>

            <tr><td class="diff-unchanged" > <br>{noformat} <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>

<h2><a name="GettingaBacktrace-Overview"></a>Overview</h2>

<p>The backtrace information is required by developers to help fix problem 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 aux | grep asterisk

root     17832  0.0  1.2   2348   788 pts/1    S    Aug12   0:00 /bin/sh /usr/sbin/safe_asterisk

root     26686  0.0  2.8  15544  1744 pts/1    S    Aug13   0:02 asterisk -vvvg -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>

<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, and impact should be negligible.</p>

<p>After Asterisk crashes, a core file will be "dumped." The most likely location for the core dump will be in your /tmp/ directory or the directory from which you started Asterisk. For the following examples, we are assuming that /tmp is the location in which your core files are dumped. To make sure the core dump is really there, you can just type the following command in your shell:</p>

<div class="preformatted panel" style="border-width: 1px;"><div class="preformattedContent panelContent">

<pre># ls -l /tmp/core.*

-rw-------  1 root root 10592256 Aug 12 19:40 /tmp/core.26252

-rw-------  1 root root  9924608 Aug 12 20:12 /tmp/core.26340

-rw-------  1 root root 10862592 Aug 12 20:14 /tmp/core.26374

-rw-------  1 root root  9105408 Aug 12 20:19 /tmp/core.26426

-rw-------  1 root root  9441280 Aug 12 20:20 /tmp/core.26462

-rw-------  1 root root  8331264 Aug 13 00:32 /tmp/core.26647

</pre>

</div></div>

<p>In the event that there are multiple core files present (as in the above example), 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.3-debian

Copyright 2004 Free Software Foundation, Inc.

GDB is free software, covered by the GNU General Public License, and you are

welcome to change it and/or distribute copies of it under certain conditions.

Type "show copying" to see the conditions.

There is absolutely no warranty for GDB.  Type "show warranty" for details.

This GDB was configured as "i386-linux".

</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" -ex "bt full" -ex "thread apply all bt" --batch -c /tmp/core.26252 &gt; /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 /tmp/core.26252 | 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 ?? ()