On Sat, 19 Jul 2008, S h i v wrote:
> 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.
It's not a concept of the language but rather of the memory allocator.
Which - is libumem. The idea is simple: Start with the global state of
libumem, build a list of memory "slabs" and their allocated/free state.
That gives you a list of all previous value-returned-by-malloc().
Then simply search the process heap / stacks for these pointers.
If the pointer (a known return value of a malloc call) is not found
anywhere in either the heap or the stack, i.e. if it is "allocated" as per
the state of the memory allocator, but not "referenced" anywhere else in
the process' address space, then it's leaked.
>
> 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?
Of course.
libumem helps catch the following problems handling the heap:
- the use of uninitialized memory
- the use of memory that was freed already
- buffer overruns (*)
libumem cannot help you directly to find:
- stack corruption (corrupted / overrun local variables)
- corruption within allocated buffers on the heap
(*) Caught on the spot only with firewalling; less-than-8 byte overruns
show in ::umem_verify (or on free).
Best regards,
FrankH.
k
