This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: Memory Leaks
- To: help-gcc at gnu dot org
- Subject: Re: Memory Leaks
- From: Greg Newby <gbnewby at ils dot unc dot edu>
- Date: 29 Nov 1999 04:33:50 GMT
- Newsgroups: gnu.gcc.help
- Organization: Information & Library Science, UNC-CH
- References: <383536D0.C1DA51E8@cable.A2000.nl> <rmcc18.vu6.ln@127.0.0.1>
- Xref: wodc7nx0 gnu.gcc.help:1997
There's a great commercial tool called Purify, made by
Rational (www.rational.com). It's quite pricey ($2400 license),
but you can download a free demo.
It searches for all memory leaks, potential memory leaks, etc.
and tells you where in your code they happen. Very handy...
I wish I could afford it (we might get an educational version
here at UNC soon). Meanwhile, I periodically download the
demo version when I'm having trouble that debuggers can't find.
This doesn't answer your question, but it's a good tool to know
about I think. It interoperates fine with gdb (that's how I
use it). I have not had much luck looking for memory leaks with
gdb - although you can spot a variable that points to unassigned
memory easily enough (e.g., if *p == NULL [0x0]), it doesn't do this
automatically. Furthermore, it doesn't enforce any kind of
coding practice, like making sure stuff you 'new' or 'malloc' is
later free'd.
-- Greg
In gnu.g++ J.H.M. Dassen (Ray) <jhm@cistron.nl> wrote:
> Fred Wan <a.wan@cable.A2000.nl> wrote:
>>Does anyone know if there are possibilities of tracing memory leaks with
>>gdb (xxgdb)?
// Gregory B. Newby, Assistant Professor in the School of Information
// and Library Science, University of North Carolina at Chapel Hill
// CB# 3360 Manning Hall, Chapel Hill, NC, 27599-3360 E: gbnewby@ils.unc.edu
// V: 919-962-8064 F: 919-962-8071 W: http://www.ils.unc.edu/~gbnewby/