On Sat, Jul 19, 2008 at 5:35 AM, Adam Leventhal <ahl at eng.sun.com> wrote: > Hi Shiv, > > Just because the process size is increasing doesn't mean that you have a > memory leak. For example: > > p = malloc(sizeof (node_t)); > p->next = list; > list = p; > > ::findleaks is only going to find buffers that aren't referenced. >
Thanks for the responses. This I gathered from Garrett's mail as well. I have taken the hint about possible incorrect handling of list/map or any such containers. For my own curiosity, how is mdb able to recognize if a memory location is still being referenced or not? Isn't the aspect of such referencing more a construct of a language (C/C++) for the debugger to know. A fresh symptom now is a signal BUS (invalid address alignment) error under dbx. My understanding is that this is likely to do with memory corruption. libumem log says all caches are clean. The problem doesn't occur in my 32-bit variant of the application. The 64-bit build is causing the problem. Are there memory corruption issues that libumem may not catch? regards Shiv
