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

[bala murugan]

Thanks a lot Richard for the response and explanation

with allocations i was able to determine where the leak would be by going
through the code(atleast 5 files) .

But i was looking for an easier way to see which piece of the code is
leaking memory to help identify the problem

there are multiple CLI commands - with no detailed info on what it is and
how to use to spot where the leak is

Is there any doc as such with example .

thanks,
Bala

On Fri, May 5, 2017 at 2:32 PM, Richard Mudgett <rmudgett at digium.com> wrote:

>
>
> 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
>
>
> --
> _____________________________________________________________________
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>    http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.digium.com/pipermail/asterisk-dev/attachments/20170508/ef4d9409/attachment.html>