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 <[email protected]> wrote: > > > On Fri, May 5, 2017 at 11:55 AM, bala murugan <[email protected]> > 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 >
-- _____________________________________________________________________ -- 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
