VC2008 C++ Memory Leaks

Question

please note my english skill is very low. but i'll try my best to explain.

I making a mfc project in Visual Studio 2008 sp1.

this Project included a static library that maked by 2008/sp1/native C++

the problem is that step:

1) build and start debug on mfc project
2) click x button on main window or alt+f4 to exit program
3) the main window is closed at once
4) but when i looking process tab of taskmgr, it still alive.
5) if i try kill mfc project process on taskmgr, it killed at once
6) but visual studio still debugging mode and very long time taken to the IDE is returnning normal.
7) the time is 5~10 minutes
8) and output log, detected memory leaks!!
9) the log is very large almost 11megabytes text

and i find the point.
1) the static library always create a library's main functional class's instance on start-up, using new operator (the start-up is static time, front of main)
2) static library's constructor has next code
note : i'm sorry i try to looking the 'Code' tab in this editor but i can't make code section so i write the code and ordering "br" html tag.

VPHYSICS::VPHYSICS(){
       m_tickflowed = 0;
       QueryPerformanceFrequency(&cpu_freq);
       SetTickTime(30);

       m_state[VPHYSTATE_SPEED_MAX]=SPEED_SCALAR_MAX;
       m_state[VPHYSTATE_LIMITED_ACCELARATION]=FALSE;
       m_state[VPHYSTATE_FRICTIONENABLE]=TRUE;
       m_state[VPHYSTATE_FRICTIONFACTOR]=1.0f;
       m_state[VPHYSTATE_GRAVITY]=9.8065f;
       m_state[VPHYSTATE_ENGINESPEED_DELAY_HIGH]=0.0f;
       m_state[VPHYSTATE_ENGINESPEED_DELAY_LOW]=0.0f;
       m_state[VPHYSTATE_FRICTION_RATIO]=1.0f;
       m_state[VPHYSTATE_DIMENSION_GLOBAL]=2;
       m_state[VPHYSTATE_COLLISION_UNFRICTIONABLE]=TRUE;
       m_state[VPHYSTATE_PAULI_EXCLUSION_ENABLE]=TRUE;
       m_state[VPHYSTATE_PAULI_EXCLUSION_RATIO]=1.0f;
       m_state[VPHYSTATE_FRICTION_SMOOTHLY]=1.0f;
       m_state[VPHYSTATE_COLLHANDLER_OUTER]=TRUE;
       m_dwSuspendedCount=0;
       InitializeCriticalSection(&m_criRegister);
       InitializeCriticalSection(&cri_out);
       ZeroMemory(m_objs,sizeof(m_objs));
       m_bThreadDestroy=FALSE;
       m_hPhysicalHandle=0;
       m_nPhysicalThread1ID=0;
       m_nTimeMomentTotalCount=0;
       m_hGarbageCollector=0;
       m_nGarbageCollectorID=0;
       m_PhyProcessIterID=NULL;
       for(DWORD i = 1 ; i < MAX_OBJECT_NUMBER ; i++)
       {
           m_objAvaliable.push_back(i);
       }
  }

//this code is my static library, using Physics Engine of Game.

and the problem is when destroying this instace.
when the delete operator calling(at end of program), it takes very long time.
when i remove the

for(DWORD i = 1 ; i < MAX_OBJECT_NUMBER ; i++)
    {
        m_objAvaliable.push_back(i);
    }

, or decrease MAX_OBJECT_NUMBER(originally it was #define MAX_OBJECT_NUMBER 100000, but i decrease it to 5 or 10), the 'long time' is disappeared!!

the type of 'm_objAvaliable' is std::list<DWORD>
this member variable seems not causing of memory leak. (because this container don't have any relation of heap allocation)
and the other project including this library don't has this problem.
(but included by mfc project is first time and i can see only this problem in this case)
Does anyone imagine a solution that problem???
if you want more information, comment to this article. i'll reply ASAP
more : it only happen in DEBUG mode. on Release mode, this problem don't occur.

Answer 1

I believe the problem you are experiencing is not, in fact, a problem at all. MFC uses it's own debug version of new (in Release mode, it uses the regular, default new). MFC does this so it can try and be helpful in telling you that you have memory leaks.

Trouble is, I think that you deallocation of the objects in the static library is occurring after MFC has decided to dump any allocations it thinks haven't been properly deallocated. Given that you have so many objects, It's spending an awfully long time dumping this stuff to the console.

At the end of the day, MFC thinks there are memory leaks when there aren't.

Your solutions are:

1. Stop MFC using DEBUG NEW. Remove any lines in your MFC project that are #define new DEBUG_NEW. The disadvantage to this method is that, of course, if you inadvertently create real memory leaks, it can't track them.

2. Have some kind of initialisation, de-initialisation functions in your static library. Call the de-initialisation function when your MFC application exits, prior to when MFC starts to trawl through allocations it still thinks exist.