|
Boost : |
From: Victor A. Wagner Jr. (vawjr_at_[hidden])
Date: 2004-05-20 22:58:32
I see they _still_ have the bug that reports all the allocates taking place
in crtdbg.h
Shame such a BIG company can't figure out how to take out an error they put
in 5 years ago </sarcasm>
At Thursday 2004-05-20 11:06, you wrote:
>While investigating shared_ptr serialization, I've come upon the VC method
>used for detecting memory leaks. I had previously used it as part of MFC
>and found it very helpful. By including the following at the beginning of
>one's test program:
>
>#define _CRTDBG_MAP_ALLOC
>#include <stdlib.h>
>#include <crtdbg.h>
>
>struct leak_reporter {
> static leak_reporter instance;
> leak_reporter(){
> _CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF |
>_CRTDBG_LEAK_CHECK_DF );
> }
> ~leak_reporter(){
>// _CrtDumpMemoryLeaks(); // replaced by the above
> }
>};
>leak_reporter leak_reporter::instance;
>
>The program displays the following in the output window while running under
>the VC IDE:
>
>Detected memory leaks!
>Dumping objects ->
>c:\program files\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689)
>: {663} normal block at 0x00325480, 24 bytes long.
> Data: < ,W > C4 2C 57 00 00 00 00 00 FF FF FF FF 00 00 00 00
>c:\program files\microsoft visual studio .net 2003\vc7\include\crtdbg.h(689)
>: {393} normal block at 0x003261F0, 24 bytes long.
> Data: < ,W > 94 2C 57 00 00 00 00 00 FF FF FF FF 00 00 00 00
>Object dump complete.
>
>The sequential number (663 and 393 in this example) can be used to trap the
>debugger at the original allocation when the test is run the next time.
>
>Is this not a worthy idea to be included in the test system - at least for
>VC? In this way we would get a report of memory leaks every time we ran a
>test.
>
>Robert Ramey
>
>
>
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Victor A. Wagner Jr. http://rudbek.com
The five most dangerous words in the English language:
"There oughta be a law"
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk