Re: memory leaks

[Kevin Buettner]

On Aug 1,  9:18am, Marina Vaillant wrote:

> Can gdb find memory leaks ?

For finding memory leaks (and other problems related to memory
allocation), I often use Gray Watson's ``dmalloc'' package.  See
http://dmalloc.com/.

It is recommended that you use dmalloc in conjunction with GDB (or
some other breakpoint debugger) for tracking such problems down.  I
believe the dmalloc documentation describes how to do this, so I won't
go into the specifics.

I once encountered a problem for which dmalloc didn't seem very
helpful.  The program in question defined its own memory allocation
and deallocation routines (which ended up calling malloc() and
free()).  The dmalloc facilities which log the calling function
weren't terribly useful because the caller was always the same, i.e,
the caller of malloc() was always the program defined allocation
routine, and the caller of free() was always the caller defined
deallocation routine.  I used GDB to track down the memory leak by
placing a breakpoint on the allocation and deallocation functions. 
Sequences of commands were then attached to each of these breakpoints
to print out the address being allocated or deallocated along with a
limited stack trace.  The final command in each sequence told GDB to
continue.  The result was that GDB would produce volumes of output
when run, but the output could be collected and the results post
processed by a script (I used Perl) to show where the leaks occurred. 
The GDB commands for setting it up looked something like this:

    break alloc
    commands
     bt 5
     finish
     continue
    end
    break dealloc
    commands
     bt 5
     print ptr                  (or whatever the name of the argument is to
                                 the deallocation routine)
     continue
    end

> I am trying to look into a core file to find the source of a
> segmentation fault caused by a realloc().
> I see using backtrace that it occurs in the realloc and in
> _malloc_unlocked().
> 
> But how can i find the source of the error? 

I'm not convinced this is a leak.  It sounds more like a buffer
overrun, underrun, or corruption caused by the program continuing to
use an already freed memory object.  In each of these cases, your
program is inadvertently corrupting some of the memory that malloc()
and company use for its own bookkeeping.  (dmalloc or Electric Fence
can be used to help track this sort of problem down.  There are
commerical products that may also be of assistance.)

In any event, while it is certainly worth looking at the post-mortem
from such a crashing program, it is frequently the case that the
corruption responsible for the crash occurred long before the actual
crash.  You might get lucky by looking at the core, but chances are
good you'll need to use some other tool which'll alert you as quickly
as possible when the corruption occurs.

Kevin