EDN Admin
Well-known member
Currently I have taken up the task to locate memory leaks in source base. I am adopting the conventional memory strategy.
Adding the necessary headers
<pre class="prettyprint #define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>[/code]
Adding _CrtDumpMemoryLeaks(); before exiting the programs.
And then based on the report generated, adding _CrtSetBreakAlloc to locate the source of any particular Allocation. I am intrigued to see certain allocations which I cannot trace back to its source. Even when I added _CrtSetBreakAlloc just after main, I
see, bunch of messages some of them as below
{3379} normal block at 0x02956870, 22 bytes long.<br/>
Data: <S y n c S e r v > 53 00 79 00 6E 00 63 00 53 00 65 00 72 00 76 00
<br/>
{3378} normal block at 0x02956820, 20 bytes long.<br/>
Data: <<[ßU ph• > 3C 5B DF 55 00 00 00 00 70 68 95 02 00 00 00 00
<br/>
{3377} normal block at 0x029567D0, 14 bytes long.<br/>
Data: <S t r i n g > 53 00 74 00 72 00 69 00 6E 00 67 00 00 00
<br/>
{3376} normal block at 0x02956780, 20 bytes long.
By seeing the block allocation number I concluded that they might be happening either at the CRT or at the MFC libraries. I have even seen references such as below
{2126} client block at 0x029EFCD8, subtype c0, 64 bytes long.<br/>
a CDynLinkLibrary object at $029EFCD8, 64 bytes long<br/>
f:ddvctoolsvc7libsshipatlmfcsrcmfcstrcore.cpp(156) : {2120} normal block at 0x029EFAB8, 28 bytes long.<br/>
Data: <ä¸ X > E4 B8 10 58 05 00 00 00 05 00 00 00 01 00 00 00
My question is, is there a general rule to determine if the messages are arising from CRT/MFC or from the application source?Please note I tried to add
<pre><tt>#define _CRTDBG_MAPALLOC</tt>[/code]
but it didnt help me much.
Any help in this regard would he highly appreciated.
<br/>
<br/>
<br/>
View the full article
Adding the necessary headers
<pre class="prettyprint #define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>[/code]
Adding _CrtDumpMemoryLeaks(); before exiting the programs.
And then based on the report generated, adding _CrtSetBreakAlloc to locate the source of any particular Allocation. I am intrigued to see certain allocations which I cannot trace back to its source. Even when I added _CrtSetBreakAlloc just after main, I
see, bunch of messages some of them as below
{3379} normal block at 0x02956870, 22 bytes long.<br/>
Data: <S y n c S e r v > 53 00 79 00 6E 00 63 00 53 00 65 00 72 00 76 00
<br/>
{3378} normal block at 0x02956820, 20 bytes long.<br/>
Data: <<[ßU ph• > 3C 5B DF 55 00 00 00 00 70 68 95 02 00 00 00 00
<br/>
{3377} normal block at 0x029567D0, 14 bytes long.<br/>
Data: <S t r i n g > 53 00 74 00 72 00 69 00 6E 00 67 00 00 00
<br/>
{3376} normal block at 0x02956780, 20 bytes long.
By seeing the block allocation number I concluded that they might be happening either at the CRT or at the MFC libraries. I have even seen references such as below
{2126} client block at 0x029EFCD8, subtype c0, 64 bytes long.<br/>
a CDynLinkLibrary object at $029EFCD8, 64 bytes long<br/>
f:ddvctoolsvc7libsshipatlmfcsrcmfcstrcore.cpp(156) : {2120} normal block at 0x029EFAB8, 28 bytes long.<br/>
Data: <ä¸ X > E4 B8 10 58 05 00 00 00 05 00 00 00 01 00 00 00
My question is, is there a general rule to determine if the messages are arising from CRT/MFC or from the application source?Please note I tried to add
<pre><tt>#define _CRTDBG_MAPALLOC</tt>[/code]
but it didnt help me much.
Any help in this regard would he highly appreciated.
<br/>
<br/>
<br/>
View the full article