Re: C++ Memory Profiling/Debugging
Hi Lou, Thanks - I'll give it a spin. I read with some reservation on http://dmalloc.com/: Dmalloc is not as good with C++ as C because the dynamic memory routines in C++ are new() and delete() as opposed to malloc() and free(). Since new and delete are usually not used as functions but rather as x = new type, there is no easy way for dmalloc to pass in file and line information unfortunately. The `libdmallocxx.a' library provides the file `dmallocc.cc' which effectively redirects new to the more familiar malloc and delete to the more familiar free. I'll give it a go anyway. Wonder if there is a C++ friendly debug tool out there... Thanks, David On Sat, 21 Feb 2004, Louis LeBlanc wrote: On 02/21/04 12:48 AM, David Carter-Hitchin sat at the `puter and typed: Hi, Does anyone out there know a good C++ memory profiling/debugging tool for FBSD? I'm looking for a tool like valgrind or purify. I grepped around in the ports directory and I found ElectricFence and mprof but these seem to be for C only (as they refer exclusively to malloc free). bohem-gc sounds like the kind of package I'm after - but I thought I ask in case anyone has better ideas... ? devel/dmalloc is pretty good. I'm using it with C on Solaris, but all you do is basically link its library into your process, set a few environment variables, and it will dump a complete list of statistics, based on the values of the environment variables. The most valuable statistic is the origin of every single memory allocation that is not freed. Simply track those made by your code (file name and line number of the malloc are given) and fix them. I found it MUCH easier to integrate and use than Efence or Purify. If your process dynamically allocates memory that isn't intended to be freed, like for internal structure allocation through the life of the process, you might include a routine that frees such pointers in your cleanup process. I have a number of things I have to clear that aren't intended to be freed during the life of the process, so I simply added them within a conditional precompiler block that only gets compiled when I'm building a memory debuggable version. You wouldn't believe the memory leaks I found in (someone else's) production code with this tool. HIGHLY recommended. Good luck. Please cc me on any replies - I had to drop out of this list sometime ago as the sheer volume was killing my mailbox... I know what you mean . . . Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://www.keyslapper.org ԿԬ Unless hours were cups of sack, and minutes capons, and clocks the tongues of bawds, and dials the signs of leaping houses, and the blessed sun himself a fair, hot wench in flame-colored taffeta, I see no reason why thou shouldst be so superfluous to demand the time of the day. I wasted time and now doth time waste me. -- William Shakespeare ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: C++ Memory Profiling/Debugging
On 02/21/04 12:48 AM, David Carter-Hitchin sat at the `puter and typed: Hi, Does anyone out there know a good C++ memory profiling/debugging tool for FBSD? I'm looking for a tool like valgrind or purify. I grepped around in the ports directory and I found ElectricFence and mprof but these seem to be for C only (as they refer exclusively to malloc free). bohem-gc sounds like the kind of package I'm after - but I thought I ask in case anyone has better ideas... ? devel/dmalloc is pretty good. I'm using it with C on Solaris, but all you do is basically link its library into your process, set a few environment variables, and it will dump a complete list of statistics, based on the values of the environment variables. The most valuable statistic is the origin of every single memory allocation that is not freed. Simply track those made by your code (file name and line number of the malloc are given) and fix them. I found it MUCH easier to integrate and use than Efence or Purify. If your process dynamically allocates memory that isn't intended to be freed, like for internal structure allocation through the life of the process, you might include a routine that frees such pointers in your cleanup process. I have a number of things I have to clear that aren't intended to be freed during the life of the process, so I simply added them within a conditional precompiler block that only gets compiled when I'm building a memory debuggable version. You wouldn't believe the memory leaks I found in (someone else's) production code with this tool. HIGHLY recommended. Good luck. Please cc me on any replies - I had to drop out of this list sometime ago as the sheer volume was killing my mailbox... I know what you mean . . . Lou -- Louis LeBlanc [EMAIL PROTECTED] Fully Funded Hobbyist, KeySlapper Extrordinaire :) http://www.keyslapper.org ԿԬ Unless hours were cups of sack, and minutes capons, and clocks the tongues of bawds, and dials the signs of leaping houses, and the blessed sun himself a fair, hot wench in flame-colored taffeta, I see no reason why thou shouldst be so superfluous to demand the time of the day. I wasted time and now doth time waste me. -- William Shakespeare ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
C++ Memory Profiling/Debugging
Hi, Does anyone out there know a good C++ memory profiling/debugging tool for FBSD? I'm looking for a tool like valgrind or purify. I grepped around in the ports directory and I found ElectricFence and mprof but these seem to be for C only (as they refer exclusively to malloc free). bohem-gc sounds like the kind of package I'm after - but I thought I ask in case anyone has better ideas... ? Please cc me on any replies - I had to drop out of this list sometime ago as the sheer volume was killing my mailbox... Thanks, David ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
