Re: memory leaks

[Jesse Marlin]

Kevin Buettner writes:
 > 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/.

I have used mpatrol with great success.  Depending on the options you can
have it generate a log of all memory ops (a stack trace), and then
produce a leak table at the end.  The leak table will tell which function
produced the leak, then you can track which allocation did not get freed.
It will also alert you to any erroneous memory operations.  You can find it
at freshmeat.net.  

 > 
 > 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
 > 
 > _______________________________________________
 > Bug-gdb mailing list
 > address@hidden
 > http://mail.gnu.org/mailman/listinfo/bug-gdb



--
Jesse Marlin
Intec Telecom Systems
Software Engineer
Main 404-705-2800
Ph 404-705-2912
Fax 404-705-2805
Email address@hidden