[asterisk-dev] Asterisk Memory Debugger (MALLOC_DEBUG) and DONT_OPTIMIZE

[Richard Mudgett]

On Fri, May 5, 2017 at 11:55 AM, bala murugan <fightwithme at gmail.com> wrote:

> Hi ,
>
> Can someone please help me understand what to look for in the
> /var/log/asterisk/mmlog to check where the leak is , since on Exit it
> throws me millions of line under Exiting with the following memory not
> freed.
>
> need some knowledge on reading this file so that i can pinpoint where the
> leak is .
>

If you exit Asterisk using "core stop now" then Asterisk does the absolute
minimum cleanup
before exiting so you will see a lot of unreleased memory.  You need to use
"core stop gracefully"
for Asterisk to clean up as much as it can before exiting.

MALLOC_DEBUG does many things for you:
* It keeps track of each block of memory that is allocated until it is
pushed out of a fixed size
freed memory holding queue.  It remembers where a block of memory was
allocated and how
large it is.
* It checks for memory writes above and below the block of memory when the
code frees memory.
If it sees the guard pattern has changed it complains of high and/or low
fence violations respectively.
* It fills the memory block with the 0xdeaddead pattern when the code frees
memory.  The memory
is then placed into a holding queue for awhile.
* It complains of memory corruption when a memory block is pushed out of
the holding queue and
the fill pattern has changed.
* If you get a crash because of a pointer trying to access the 0xdeaddead
(0xdeaddeaddeaddead)
fill pattern address then you know someone was using a freed block of
memory.  The pattern was
specifically chosen to cause a crash and be obvious for this reason.
* It gives you live allocation reports using "memory show summary".  You
can then watch
memory leaks consuming more and more memory.
* It gives you an unfreed allocation list on Asterisk shutdown when
requested.

Memory leaks are shown by a lot of allocations from an allocation location
that are never released.
The larger the leak the more allocations that are never released.  You
should be able to narrow it
down by noting which allocations don't seem to be freed because the number
of the allocations
from a location keeps increasing.

Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170505/48517ce0/attachment.html>