On Fri, May 5, 2017 at 11:55 AM, bala murugan <fightwit...@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