Why does the memory allocation number keep changing for the same memory leak in VS2015 MFC?

Question

I'm trying to remove memory leaks in my app using VS2015 and MFC in VC++. The answers to this similar question did not help: How to detect memory leak when memory allocation number isn't always same?

In Configuration Properties>C/C++>Code Generation, I changed the option selected for Runtime Library from /MT to /MTd.
The app is not multi-threaded(afaik).

The memory allocation number changes between program runs, leading me to different places in the code.
The procedure I use worked well before:
I copy a memory allocation number from the previous memory leakage report, and start the app.
When it stops at the breakpoint, I go to the Watch Window, and paste it in the value column of _crtBreakAlloc. (Eg _crtBreakAlloc 1171).
Then run the program on until it breaks, and use the Call Stack to locate the unfreed object.

// Example of the memory report
...
{1171} client block at 0x088157A0, subtype c0, 224 bytes long.
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dumpcont.cpp(23) : atlTraceGeneral -     a ProgressBar object at $088157A0, 224 bytes long
{223} normal block at 0x01E79600, 324 bytes long.
 Data: <                > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
...

// Example of the next report
...
{1112} client block at 0x08B30480, subtype c0, 224 bytes long.
f:\dd\vctools\vc7libs\ship\atlmfc\src\mfc\dumpcont.cpp(23) : atlTraceGeneral - a ProgressBar object at $08B30480, 224 bytes long
{223} normal block at 0x01F693D8, 324 bytes long.
 Data: <                > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
 ...

Note the memory allocation number "1171" changes to "1112", also affecting all the numbers above it.
This happens even after starting the PC with only VS2015 opened, and doing nothing between adjacent runs of the program. I keep each run of the program exactly the same each time, doing the same things, in the same order. E.g. load the same file, press the same buttons/keys etc.

To remap operator new, the code has-

//stdafx.h
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
#ifdef _DEBUG
    #define DBG_NEW new ( _NORMAL_BLOCK , __FILE__ , __LINE__ )
#else
    #define DBG_NEW new
#endif

// CImage.h : main header file for the CImage application
#define _CRTDBG_MAP_ALLOC // Supports memory leakage detection.
#include <stdlib.h>
#include <crtdbg.h>
#ifdef _DEBUG
    #ifndef DBG_NEW
        #define DBG_NEW new ( _NORMAL_BLOCK , __FILE__ , __LINE__ )
    #endif
#endif

Any help will be very much appreciated. Thank you

xMRi xMRi · Accepted Answer · 2017-11-10T07:51:51

There are many answers to this. Your shown code isn't specific enough to tell you more.

Do you spawn other threads in the init code? This will change the behaviour, because the sequence of execution isn't guaranteed.
When you terminate your program, you UI usually also saves it state (MFC-Next). This state is loaded again, when you start again. Different UI settings may cause it.
Different data. Even breaking a different command line or any other different input string into CString or std::string elements may cause a shift. Because depending on the input.
Even when creating windows, some message processing might differ from start to start of the program, depending on when timer and paint messages will take place.
I am sure that there are other reasons that I missed... this list may grow...

In your case it is a very early stage when I see the allocation number. And looking at the objects name that is reported in your question, I am sure it has to do with the UI.

So it may help, to clear all registry entries of your program, and make sure that the input data is really the same.

Even it should help, to break into your code in an earlier stage. (i.E. at allocation 1100). Step over and out and look what happens in your code. Watch the allocation count in the watch window.
There are so many allocations, so I am sure that you find the code fast and easy with a few steps.

Why does the memory allocation number keep changing for the same memory leak in VS2015 MFC?

1 Answers