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, -- 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 ………………………………………..…………………
"Jamie Cook" <jimi.cook@gmail.com> wrote in message news:d95fba6c0801151506r127233ffj3ca54808e64784fc@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
Jamie Cook wrote:
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? ;)
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/MemoryLeakDetect... 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. On Jan 20, 2008 9:13 AM, Serge Skorokhodov <serge.skorokhodov@tochka.ru> wrote:
Jamie Cook wrote:
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? ;)
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Klaim <mjklaim <at> gmail.com> writes:
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/MemoryLeakDetect... 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
participants (4)
-
Gennadiy Rozental -
Jamie Cook -
Klaim -
Serge Skorokhodov