[asterisk-dev] Asterisk created mmlog

Matthew Jordan mjordan at digium.com
Sat Dec 20 23:27:39 CST 2014


On Sat, Dec 20, 2014 at 10:44 AM, bala murugan <fightwithme at gmail.com> wrote:
> Hi ,
>     I am trying to understand the content written to mmlog file looks like
> it is difficult , with this how I can find where is memory leak happening is
> there any document on this what to look for and all the cli commands and how
> to use to find where is memory leak .
>

A few assumptions:

(1) When you say mmlog, I'm going to assume that you've enabled the
MALLOC_DEBUG build option via menuselect. mmlog is the log file
generated when that build option is enabled, but MALLOC_DEBUG enables
more than just that log file.

(2) I'm going to assume you are using the latest in one of the
supported branches (or at least one of the more recently supported
branches), as there have been enhancements to MALLOC_DEBUG along the
way.

You can think of MALLOC_DEBUG as a "poor man's valgrind memory
checker". Like valgrind, it can help spot memory leaks and potential
corruptions. It will generally impact performance far less than
valgrind (which is good); on the other hand, it provides less
information and cannot catch as many incidents of memory
corruption/leaking as valgrind (which is bad). If you can reproduce an
error in valgrind, you're generally better off using it. If your
system cannot run under valgrind or you can't reproduce your situation
in a lab environment with valgrind, then sometimes MALLOC_DEBUG can
help you.

The CLI commands provided by MALLOC_DEBUG are documented on the wiki:

https://wiki.asterisk.org/wiki/display/AST/MALLOC_DEBUG+Compiler+Flag

Several of these CLI commands are useful for diagnosing memory leaks.

As far as the entries logged to mmlog during operation, these come
from errors detected in astmm.c, which fronteds the C library memory
functions when MALLOC_DEBUG is enabled. You can inspect astmm.c for
the various errors it can detect - typically, it will detect:
* allocation failures
* attempts to free memory that is already free'd
* corrupted memory

Matt

-- 
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org



More information about the asterisk-dev mailing list