Re: [Boost-users] Memory Leak Detection output format
Try building with internal STL. After all you only interested in your own leaks, right?
Gennadiy
yeah I am, and having every test run spit back four blocks of unfreed memory makes it harder to see which memory leaks are from my code and which are from stlport - especially if there is no contextual information such as file/line# to distinguish them, I basically have to memorize the sizes of each leak and compare back against those on each run. Hence why I really want to either a) Find out where this last 1280 bytes of memory is being allocated b) Have filename/line# output so that it's easier to see which leaks are from my own code Which is why I'm wondering if there is a way to change the output of the memory leak detector ... guess I might have to start looking at external leak detectors that are linked at runtime instead... does anyone know any good ones? Kindly, Jamie Cook Research Engineer ………………………………………..………………… Veitch Lister Consulting Pty Ltd. Ground Floor, 80 Jephson St, PO Box 1054, Toowong, QLD 4066 AUSTRALIA Ph: +61 7 3870 4888 Fax: +61 7 3870 4446 Email: jamie.cook@veitchlister.com.au Web: www.veitchlister.com.au ………………………………………..…………………
[Please do not mail me a copy of your followup]
boost-users@lists.boost.org spake the secret code
memory leak detector ... guess I might have to start looking at external leak detectors that are linked at runtime instead... does anyone know any good ones?
I've had good results with Purify, which is now offered through IBM's since their acquisition of Rational. You can get a 15-day free trial license and download it from their web site. http://www-306.ibm.com/software/awdtools/purifyplus/ -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/
Hi, I am not sure on what platform you are looking for tools to detect memory leaks. Assuming on M$ (windows): 1. DebugDiag 2. UMDH These are available for free from MS and are very useful. Though, it requires you to perform multiple actions before being able to drill down into the code. -dky -- Contents reflect my personal views only!
On Fri, Jan 18, 2008 at 01:05:16PM +0530, dhruva wrote:
I am not sure on what platform you are looking for tools to detect memory leaks.
Assuming on M$ (windows): 1. DebugDiag 2. UMDH
I would use valgrind (at least on Linux and x86, it doesn't work for many other platforms such as Mips :-() For programs using only malloc there should be many more alternatives such as electric fence, ...
These are available for free from MS and are very useful. Though, it
Where free means probably without source code ...
requires you to perform multiple actions before being able to drill down into the code.
valgrind doesn't require this but using compiled debug information in your program is a good idea. Maybe it works even with Cygwin? As it is also a memory access checker it is a very good tool (but not cross platform!!!)! Jens
These are available for free from MS and are very useful. Though, it
Where free means probably without source code ...
And that matters why? I doubt you get the source with Purify either, doesn't stop it working....and it costs a lot more than, er, the zero you pay for the MS offering quoted. This message (including any attachments) contains confidential and/or proprietary information intended only for the addressee. Any unauthorized disclosure, copying, distribution or reliance on the contents of this information is strictly prohibited and may constitute a violation of law. If you are not the intended recipient, please notify the sender immediately by responding to this e-mail, and delete the message from your system. If you have any questions about this e-mail please notify the sender immediately.
[Please do not mail me a copy of your followup] boost-users@lists.boost.org spake the secret code <20080118075713.GB21375@imkf-pc073.imkf.tu-freiberg.de> thusly:
These are available for free from MS and are very useful. Though, it
Where free means probably without source code ...
I understand your point, but seriously, if you got a memory leak debugging tool that required you to inspect the *source* to it, would you use it? To me, requiring a look at the source would mean that the leak tool itself had a problem, which would make me just discard that tool and look for another one that didn't have a problem. -- "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/
So why, don't you switch to regualr STL and use macros I recommended?
Gennadiy
"Jamie Cook"
Try building with internal STL. After all you only interested in your own leaks, right?
Gennadiy
yeah I am, and having every test run spit back four blocks of unfreed memory makes it harder to see which memory leaks are from my code and which are from stlport - especially if there is no contextual information such as file/line# to distinguish them, I basically have to memorize the sizes of each leak and compare back against those on each run. Hence why I really want to either a) Find out where this last 1280 bytes of memory is being allocated b) Have filename/line# output so that it's easier to see which leaks are from my own code
participants (6)
-
dhruva -
Gennadiy Rozental -
Hughes, James -
Jamie Cook -
Jens Seidel -
legalize+jeeves＠mail.xmission.com