[Boost-users] Memory Leak Detection output format
Jamie Cook
I'm using the boost.test unit tests with memory leak detection turned on and I'm slightly puzzled about the format of the output. I've been working on getting boost to play nicely with STLport and one of the 'problems' I'm having is with memory leaks being reported by boost.test which are actually coming from stlport (there is a discussion on their FAQ about how these aren't really memory leaks at all but that is beside the point). I've managed to get rid of most of these leaks but I've still got one hanging around and I don't know where it comes from. My output from my testing looks like this
Embedding manifest...
Performing Post-Build Event...
*** No errors detected
Running 1 test case...
Detected memory leaks!
Dumping objects ->
{171} normal block at 0x00378B88, 1280 bytes long.
Data: < 7 lationStatis> A8 8D 37 00 6C 61 74 69 6F 6E 53 74 61 74 69 73
Object dump complete.
My question is this... how can I enable more informative memory leak output? In this article () it says that by #define _CRTDBG_MAP_ALLOC, the filename and line number will also be displayed. I'm looking into execution_monitor.ipp and I can see where < crtdbg.h> is included but even if I put the #define directly before this include the output comes out exactly the same as above. (and yes I recompiled the library)
I'm using MSVC8.0, boost 1.34.1 and stlport 5.1.4 and the test library is compiled as
C:\Program Files\boost\boost_1_34_1\libs\test\build>bjam --toolset=msvc link=static stdlib=stlport threading=multi
I would really appreciate if anyone could give me some insight on why this is being reported in such a way that I can't actually use it.
Cheers,
--
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...@veitchlister.com.au
Web: www.veitchlister.com.au
………………………………………..…………………
Gennadiy Rozental
> "Jamie Cook" <jimi...@gmail.com> wrote in message
> news:d95fba6c0801151506r127...@mail.gmail.com...
> Hi all,
>
> I'm using the boost.test unit tests with memory leak detection turned on
> and I'm slightly puzzled about the format of the output.
> I've been working on getting boost to play nicely with STLport and one of
> the 'problems' I'm having is with memory leaks being
> reported by boost.test which are actually coming from stlport (there is a
> discussion on their FAQ about how these aren't really
> memory leaks at all but that is beside the point). I've managed to get rid
> of most of these leaks but I've still got one hanging around > and I don't
> know where it comes from. My output from my testing looks like this
>
> Embedding manifest...
> Performing Post-Build Event...
> *** No errors detected
> Running 1 test case...
> Detected memory leaks!
> Dumping objects ->
> {171} normal block at 0x00378B88, 1280 bytes long.
> Data: < 7 lationStatis> A8 8D 37 00 6C 61 74 69 6F 6E 53 74 61 74 69 73
> Object dump complete.
>
> My question is this... how can I enable more informative memory leak
> output? In this article () it says that by #define
what article?
> _CRTDBG_MAP_ALLOC, the filename and line number will also be displayed.
> I'm looking into execution_monitor.ipp and I can > see where < crtdbg.h>
> is included but even if I put the #define directly before this include the
> output comes out exactly the same as > above. (and yes I recompiled the
> library)
I has nothing to do with library _CRTDBG_MAP_ALLOC has to be defined ding
test module compilation
> I'm using MSVC8.0, boost 1.34.1 and stlport 5.1.4 and the test library is
> compiled as
> C:\Program Files\boost\boost_1_34_1\libs\test\build>bjam --toolset=msvc
> link=static stdlib=stlport threading=multi
>
> I would really appreciate if anyone could give me some insight on why this
> is being reported in such a way that I can't actually use > it.
I've tried to use it. I added new int; to simple unit test. I can't say
this macro is really usefull. Maybe would you be using malloc instead of new
it produce better report.
Detected memory leaks!
Dumping objects ->
....\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689) : {208}
normal block at 0x003262A8, 4 bytes long.
Data: < > CD CD CD CD
Object dump complete.
The better way I found is to use debug version of new instead
#ifdef _DEBUG
#define BOOST_TEST_DEBUG_NEW new( _CLIENT_BLOCK, __FILE__, __LINE__)
#define new BOOST_TEST_DEBUG_NEW
#else
#define BOOST_TEST_DEBUG_NEW
#endif
This one produces following report:
Detected memory leaks!
Dumping objects ->
.....\unit_test_example_01.cpp(33) : {208} client block at 0x003262A0,
subtype 0, 4 bytes long.
Data: < > CD CD CD CD
Object dump complete.
Gennadiy
_______________________________________________
Boost-users mailing list
Boost...@lists.boost.org
http://lists.boost.org/mailman/listinfo.cgi/boost-users
Jamie Cook
I've followed your advice but with little luck :( I have a very simple test project which is not still giving me the same old output
my std_afx.h (precompiled headers are turned off)
// -----------------------------------------------------------------------------------------------------------
#pragma once
#define _CRTDBG_MAP_ALLOC
#include <crtdbg.h>
// #ifdef _DEBUG
// #include <new>
// #define BOOST_TEST_DEBUG_NEW new( _CLIENT_BLOCK, __FILE__, __LINE__)
// #define new BOOST_TEST_DEBUG_NEW
// #else
// #define BOOST_TEST_DEBUG_NEW
// #endif
#define BOOST_TEST_MAIN
#include <boost/test/unit_test.hpp>
#include <boost/test/floating_point_comparison.hpp>
#include <boost/filesystem.hpp>
// Windows Header Files:
#define WIN32_LEAN_AND_MEAN // Exclude rarely-used stuff from Windows headers
#include <windows.h>
// -----------------------------------------------------------------------------------------------------------
my test cpp file
// -----------------------------------------------------------------------------------------------------------
#include "std_afx.h"
#include <iostream>
BOOST_AUTO_TEST_CASE( SimpleTestCase )
{
int i = 9;
i++;
int * j = new int[101];
}
// -----------------------------------------------------------------------------------------------------------
and this generates the following output when i run the executable...
================================================
Running 1 test case...
*** No errors detected
Detected memory leaks!
Dumping objects ->
Data: < > CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD CD
{164} normal block at 0x00368158, 1280 bytes long.
Data: <x 6 lationStatis> 78 83 36 00 6C 61 74 69 6F 6E 53 74 61 74 69 73
Object dump complete.
================================================
As you can see the test case introduces an easy to spot memory leak of 101 integers (at 4 bytes a pop = 404 bytes). I've done this with your debug block uncommented and the output is exactly the same... One thing I did have to do to get that block to compile was add the #include <new>, if that wasn't there I got an error from stlport stating that
c:\program files\stlport-5.1.4\stlport\stl\_new.h(47) : fatal error C1189: #error : Cannot include native new header as new is a macro.--
I think the problem is that even though I've compiled stlport with settings telling it to use regular old new/delete and not it's own super-duper new/delete, that it is still using it's own internal versions of 'regular' new and delete... I'll try fiddling with some options in stlport unless you can think of any other reason it would continue to have this behaviour?
Gennadiy Rozental
Jamie Cook
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,
Gennadiy Rozental
"Jamie Cook" <ja...@ieee.org> wrote in message news:d95fba6c0801171359q293...@mail.gmail.com...
Richard
boost...@lists.boost.org spake the secret code
<d95fba6c0801171359q293...@mail.gmail.com> thusly:
>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/>
dhruva
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!
Jens Seidel
> 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
Hughes, James
>
> 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.
Dieter Rosch
You might want to do a google for VLD (Visual Leak Detector).
It is an excellent free memory leak detector for MSVC 8.
From:
boost-use...@lists.boost.org
[mailto:boost-use...@lists.boost.org] On Behalf Of Jamie Cook
Sent: 16 January 2008 01:07 AM
To: boost...@lists.boost.org
Subject: [Boost-users] Memory Leak Detection output format
Hi all,
I'm using the boost.test unit tests with memory leak detection turned on and
I'm slightly puzzled about the format of the output. I've been working on
getting boost to play nicely with STLport and one of the 'problems' I'm having
is with memory leaks being reported by boost.test which are actually coming
from stlport (there is a discussion on their FAQ about how these aren't really
memory leaks at all but that is beside the point). I've managed to get rid of
most of these leaks but I've still got one hanging around and I don't know
where it comes from. My output from my testing looks like this
Embedding manifest...
Performing Post-Build Event...
*** No errors detected
Running 1 test case...
Detected memory leaks!
Dumping objects ->
{171} normal block at 0x00378B88, 1280 bytes long.
Data: < 7 lationStatis> A8 8D 37 00 6C 61 74 69 6F 6E 53 74
61 74 69 73
Object dump complete.
My question is this... how can I enable more informative memory leak output? In
this article () it says that by #define _CRTDBG_MAP_ALLOC, the filename and
line number will also be displayed. I'm looking into execution_monitor.ipp and
I can see where < crtdbg.h> is included but even if I put the #define
directly before this include the output comes out exactly the same as above.
(and yes I recompiled the library)
I'm using MSVC8.0, boost 1.34.1 and stlport 5.1.4 and the test library is
compiled as
C:\Program Files\boost\boost_1_34_1\libs\test\build>bjam --toolset=msvc
link=static stdlib=stlport threading=multi
I would really appreciate if anyone could give me some insight on why this is
being reported in such a way that I can't actually use it.
Cheers,
--
Richard
boost...@lists.boost.org spake the secret code
<20080118075...@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/>
_______________________________________________
Jamie Cook
I've actually already found VLD, however I had some small problems with it... firstly it's a compile time library meaning that I'd have to include it into the stlport source and compile it in from the ground up rather than just linking. While this is doable (with a bit of work) my second problem was that it caused random crashes in my application ... this was much harder to work around :)
Thanks to all for the suggestions however - has anyone ever had any luck with mpatrol? I've got the source downloaded however development stopped in 2001 as far as I can tell.
Jamie
Serge Skorokhodov
> Hi all,
>
> I'm using the boost.test unit tests with memory leak detection turned on
<skip>
> Running 1 test case...
> Detected memory leaks!
> Dumping objects ->
> {171} normal block at 0x00378B88, 1280 bytes long.
> Data: < 7 lationStatis> A8 8D 37 00 6C 61 74 69 6F 6E 53 74 61 74 69 73
> Object dump complete.
>
> My question is this... how can I enable more informative memory leak
> output?
<skip>
It looks like standard output of MS debug runtime. How can it be
improved? ;)
Klaim
I tested the MVS memory leak detector few months ago and it don't seem return the allocation file path until you use "malloc" instead of "new". (at least in my tests - tried with an empty application) It's a shame.
Anyway, there is another way to add more informations if you can run your application with exactly the same state twice. I discovered it maybe 30 minutes ago and it worked well for my case.
As stated there : http://www.oneunified.net/blog/Personal/SoftwareDevelopment/MemoryLeakDetection.article
and there : http://winter.eecs.umich.edu/soarwiki/Tracking_down_memory_leaks
you can add a breakpoint on a specific leaking memory allocation (between brackets in the debug log) by setting _crtBreakAlloc variable to it's allocation id
Like in the last link exemple, on the start of you main() :
#ifdef _MSC_VER
//_crtBreakAlloc = 1828; // uncomment that line and set the leaking memory allocation id instead of 1828
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
#endif // _MSC_VER
The MSDN docs are not verry explicit about that ( neither for vc8 nor vc9 ).
Hope that helps.
Joël Lamotte.
Gennadiy Rozental
>
>
> Hello,I tested the MVS memory leak detector few months ago
> and it don't seem return the allocation file path until you use
> "malloc" instead of "new". (at least in my tests - tried with an empty
> application) It's a shame.
> Anyway, there is another way to add more informations if you
> can run your application with exactly the same state twice. I
> discovered it maybe 30 minutes ago and it worked well for my case.As stated
there :
>
http://www.oneunified.net/blog/Personal/SoftwareDevelopment/MemoryLeakDetection.articleand
there :
>
> http://winter.eecs.umich.edu/soarwiki/Tracking_down_memory_leaksyou
> can add a breakpoint on a specific leaking memory allocation (between
Boost.Test does it for already. You can specify allocation to break on:
--detect_memory_leak=<number>
Unfortunately I found it not that easy to use. It looks "testing tool affect the
test" issue. If you specify the number CRT allocation follows a bit different
path and allocation at fault has different although close to the original
number. You will need to play with it to find correct allocation.
Gennadiy