Versions Compared


  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: edits for details about verifying your backtrace for DONT_OPTIMIZE and DEBUG_THREADS


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 followingcompiled with DONT_OPTIMIZE:

Code Block
<value optimized out>

If you are seeing the above text in your backtrace, then you likely haven't compiled with DONT_OPTIMIZE. The impact of DONT_OPTIMIZE is negligible on most systems, so go ahead and enable it as with optimizations the backtraces are often not useful to the developers. Be sure you've enabled the DONT_OPTIMIZE flag within the Compiler Flags section of menuselect. After doing so, be sure to run 'make && make install' and restart Asterisk.


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.

If you are getting a backtrace for a deadlock then be sure you compiled with DEBUG_THREADS. One way to verify this is by checking your backtrace for a thread calling ast_rentrancy_lock. For example:

No Format
#2  0x0813c6c7 in ast_reentrancy_lock (lt=0x6b736972) at /usr/local/src/asterisk-11.14/asterisk-11.14.0-rc1/include/asterisk/lock.h:420
        res = 135518668

If unsure, simply add the compiler flag in menuselect and recompile then reinstall Asterisk.

Identifying Potential Memory Corruption