From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Newby To: help-gcc@gnu.org Subject: Re: Memory Leaks Date: Sun, 28 Nov 1999 21:07:00 -0000 Message-id: <81svne$duu$1@fddinewz.oit.unc.edu> References: <383536D0.C1DA51E8@cable.A2000.nl> X-SW-Source: 1999-11/msg00427.html 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) wrote: > Fred Wan 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/ From mboxrd@z Thu Jan 1 00:00:00 1970 From: Greg Newby To: help-gcc@gnu.org Subject: Re: Memory Leaks Date: Tue, 30 Nov 1999 23:28:00 -0000 Message-ID: <81svne$duu$1@fddinewz.oit.unc.edu> References: <383536D0.C1DA51E8@cable.A2000.nl> X-SW-Source: 1999-11n/msg00427.html Message-ID: <19991130232800.qYTxId7uRU_tdUyQ1PzHLO2AgxT8dbzLfRo-HOUHU94@z> 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) wrote: > Fred Wan 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/