<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 5, 2017 at 11:55 AM, bala murugan <span dir="ltr"><<a href="mailto:fightwithme@gmail.com" target="_blank">fightwithme@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hi , <div><br></div><div>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.</div><div><br></div><div>need some knowledge on reading this file so that i can pinpoint where the leak is .</div></div></blockquote><div><br></div><div>If you exit Asterisk using "core stop now" then Asterisk does the absolute minimum cleanup<br></div><div>before exiting so you will see a lot of unreleased memory.  You need to use "core stop gracefully"<br></div><div>for Asterisk to clean up as much as it can before exiting.<br><br></div><div>MALLOC_DEBUG does many things for you:<br></div><div>* It keeps track of each block of memory that is allocated until it is pushed out of a fixed size<br>freed memory holding queue.  It remembers where a block of memory was allocated and how<br>large it is.<br></div><div>* It checks for memory writes above and below the block of memory when the code frees memory.<br>If it sees the guard pattern has changed it complains of high and/or low fence violations respectively.<br>* It fills the memory block with the 0xdeaddead pattern when the code frees memory.  The memory<br>is then placed into a holding queue for awhile.<br></div><div>* It complains of memory corruption when a memory block is pushed out of the holding queue and<br></div><div>the fill pattern has changed.<br></div><div>* If you get a crash because of a pointer trying to access the 0xdeaddead (0xdeaddeaddeaddead)<br>fill pattern address then you know someone was using a freed block of memory.  The pattern was<br></div><div>specifically chosen to cause a crash and be obvious for this reason.<br></div><div>* It gives you live allocation reports using "memory show summary".  You can then watch<br></div><div>memory leaks consuming more and more memory.<br></div><div>* It gives you an unfreed allocation list on Asterisk shutdown when requested.<br></div><div><br></div>Memory leaks are shown by a lot of allocations from an allocation location that are never released.<br>The larger the leak the more allocations that are never released.  You should be able to narrow it<br>down by noting which allocations don't seem to be freed because the number of the allocations<br>from a location keeps increasing.<br><div><br></div><div>Richard<br></div></div><br></div></div>