Re: memory leak in a MFC application

From:

ssylee <stanigator@gmail.com>

Newsgroups:

microsoft.public.vc.mfc

Date:

Fri, 3 Apr 2009 10:36:12 -0700 (PDT)

Message-ID:

<d7c3f09f-d207-44d1-94df-1de25e9e7177@p6g2000pre.googlegroups.com>

On Mar 27, 8:56 am, Joseph M. Newcomer <newco...@flounder.com> wrote:

I never used the memory state functions, so I can't answer the question. =

Whenever I have a leak I can't find quickly, I use the _crtBreakAlloc tec=

hnique. I

usually find it within a few minutes. Note that fixing it can take lon=

ger.

A classic case is of the form

void whatever()
        {
         Thing * t = new Thing;
        ...lots of computations
                  return;
                delete t;
               }

Another is getting an exception thrown; you need to do

        Thing * t = new Thing;
        try {
            ... lots of computations
             }
        catch(...)
            {
             delete t;
             throw;
                    }

note that in place of ... (which has some problems) I usually do catch(CE=

xception *) in

MFC programming.

The major causes of leaks are:
Forgetting to delete something (the most common cause)
Not all paths that leave the context delete the object, a=

lthough they should

Exceptions do not cause deletion, although they should
Destructors fail to delete components (a special case of =

forgetting to delete)

The use of smart pointers often takes care of the Forgetting/Not all path=

s/Exceptions

situations these days.

=

joe

On Thu, 26 Mar 2009 15:37:58 -0700 (PDT), ssylee <staniga...@gmail.com> w=

rote:

On Mar 26, 12:16 pm, Joseph M. Newcomer <newco...@flounder.com> wrote:

Your evaluation suggests that DoNeedle is the source of the problem. =

If you can do

something that produces the *same* values, {898} for example, then you=

can find the source

of the leak fairly easily.

Use the debugger to set the variable _crtBreakAlloc to the number you =

see (898 in the

example below) and you will get a debug break when that is allocated. =

Track back in the

stack to see who is allocating it. and you will know what allocation i=

s not being freed.

Note that a lot of the files generate by Microsoft include the declara=

tion

#ifdef _DEBUG
#define new DEBUG_NEW
#endif

If you are writing files that were not generated by the wizards, add t=

hose lines at the

front, and you will get the filename/line info in your debug report.
=

joe

On Wed, 25 Mar 2009 15:42:04 -0700 (PDT), ssylee <staniga...@gmail.com=

wrote:

I have a single-document view MFC application as attached to this lin=

(https://www.yousendit.com/download/UmNMZGVkNEhkMnV4dnc9PQ). This
application would need to link with OpenGL libraries and dlls in orde=

to run. In addition, Intel Math Kernel Library (or Intel Compiler)
needs to be installed on the system in order for the application to
run.

My memory leak problem, at least I found, has something to do with
this snippet in CsplitterView::OnTimer handler:

           if(startsim && needlemodel)
           {
                   //theMesh->NodesRepoint(needl=

emodel->Xall);

theMesh->nodesdeleteignore =

= true; // change this parameter's

scope back to private
                   startsim = false;
           }

           if (theMesh->nodesdeleteignore &&
                   needlemodel)
           {
                   if (count < needlemodel->need=

leBasePos.entries)

{
needlemodel->=

DoNeedle(&(needlemodel->needleBasePos.nodepts

[6*count]));
                           count++;
                   }
           }

If "needlemodel->DoNeedle(&(needlemodel->needleBasePos.nodepts
[6*count]));" gets commented out, I don't see any memory leak problem
showing up in the debug window. If that function is called on a
consistent basis as the "Start" button in the application is pressed,
as I close the window, I see a group of memory leak messages from
Visual Studio debug output as indicated:

Detected memory leaks!
Dumping objects ->
{898} normal block at 0x04415428, 480128 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD =

CD CD CD CD CD CD

CD
{897} normal block at 0x02E4F8C0, 13184 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD =

CD CD CD CD CD CD

CD
{896} normal block at 0x02E4C380, 120 bytes long.
Data: < (TA > C0 F8 E4 02 28 54 41 04 00 00 0=

0 00 00 00 00

00
{895} normal block at 0x02E4C500, 13184 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD =

CD CD CD CD CD CD

CD
{894} normal block at 0x046A0040, 935040 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD =

CD CD CD CD CD CD

CD
{889} normal block at 0x043A0068, 480128 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD =

CD CD CD CD CD CD

CD
{888} normal block at 0x02E4C448, 120 bytes long.
Data: <h : @ j > 68 00 3A 04 40 00 6A 04 00 C5 E4 02=

00 00 00

00
Object dump complete.

I have used the memory profiler as well as data debug point in Visual
Studio debugger to check when the data in any one of the addresses as
indicated in the previous message change. However, I have found them
to be changing and allocated in Microsoft-implemented function calls
that I have no idea of. I suspect I'm using the MFC API improperly
somewhere in the project, but I have no idea what. After doing some
search on the internet, I have tried setting a breakpoint on a memory
allocation number (http://msdn.microsoft.com/en-us/library/w2fhc9a3(V=

80).aspx), but have not much luck either.

When I ran the same function in a separate console project, I don't
see the same errors in the debug output window. You can try running i=

for yourselves as I have attached the project to this link (https://
www.yousendit.com/download/UmNMZGVYQzNEa1ZjR0E9PQ). Again, Intel Math
Kernel Library needs to be installed before this application can be
run properly.

Sorry for the long email. Would really appreciate the explanation of
what's going on.

Joseph M. Newcomer [MVP]
email: newco...@flounder.com
Web:http://www.flounder.com
MVP Tips:http://www.flounder.com/mvp_tips.htm

Thanks for the videos and links in terms of memory leak finding
tutorials. I have added the MFC CMemoryState object instantiation and
method calls in the following manner in splitterView.cpp where
DoNeedle is being called:

if(startsim && needlemodel)
{
//theMesh->NodesRepoint(needlemo=

del->Xall);

theMesh->nodesdeleteignore = t=

rue; // change this parameter's

scope back to private
                   startsim = false;
           }

           if (theMesh->nodesdeleteignore &&
                   needlemodel)
           {
                   if (count < needlemodel->needleB=

asePos.entries)

{
#if _DEBUG
CMemoryState old=

state, newstate, diffstate;

oldstate.Checkpo=

int();

#endif

// Note: memory =

leak indeed comes from this function

// need to deter=

mine the meaning of the memory leak diagnostics

needlemodel->DoN=

eedle(&(needlemodel->needleBasePos.nodepts

[6*count]));
count++;

#if _DEBUG
newstate.Checkpo=

int();

if(diffstate.Dif=

ference(oldstate, newstate))

{
=

AfxMessageBox("Memory Leak Detected");

diffstate.DumpAllObjectsSince();

                           }
#endif
                   }
           }

The message box does pop up on certain calls to DoNeedle function.
However, as I step through the code inside DoNeedle in the debugger on
the cases where the memory state has changed, I can't find any new
memory allocations (at least the one that I have made anyway). I am
extremely certain that all the malloc/free pairs in the DoNeedle
function are paired properly in the Needle3D class from my search in
that project. There are no new/delete pairs in the Needle3D class. I
have no knowledge in terms of context of the additional new operator
calls that are called. Below is the printout of the
DumpAllObjectsSince function during a particular instance.

Dumping objects ->
{661} normal block at 0x119B58C8, 480128 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD =

CD CD CD CD CD

CD
{660} normal block at 0x02E896E0, 13184 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD =

CD CD CD CD CD

CD
{659} normal block at 0x02E860D8, 120 bytes long.
Data: < X > E0 96 E8 02 C8 58 9B 11 00 00 00=

00 00 00 00

00
{658} normal block at 0x02E86320, 13184 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD =

CD CD CD CD CD

CD
{657} normal block at 0x11E50040, 935040 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD =

CD CD CD CD CD

CD
{652} normal block at 0x11940068, 480128 bytes long.
Data: < > CD CD CD CD CD CD CD CD CD CD =

CD CD CD CD CD

CD
{651} normal block at 0x02E85F78, 120 bytes long.
Data: <h @ c > 68 00 94 11 40 00 E5 11 20 63 E8 0=

2 00 00 00

00
f:\rtm\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {236}
normal block at 0x02E862C8, 22 bytes long.
Data: < >x > EC 97 3E 78 05 00 00 00 05 00 00=

00 01 00 00

00
f:\rtm\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {222}
normal block at 0x00369320, 25 bytes long.
Data: < >x > EC 97 3E 78 08 00 00 00 08 00 00=

00 01 00 00

00
f:\rtm\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(173) : {218}
normal block at 0x02E85CC0, 56 bytes long.
Data: < >x' ' > EC 97 3E 78 27 00 00 00 27 00 00 00 =

01 00 00

00
f:\rtm\vctools\vc7libs\ship\atlmfc\src\mfc\array_p.cpp(110) : {217}
normal block at 0x02E85C70, 20 bytes long.
Data: < 6 > 00 00 00 00 D4 91 36 00 00 00 00=

00 CD CD CD

CD
f:\rtm\vctools\vc7libs\ship\atlmfc\src\mfc\array_p.cpp(67) : {216}
normal block at 0x02E85C30, 4 bytes long.
Data: < > 00 00 00 00
f:\rtm\vctools\vc7libs\ship\atlmfc\src\mfc\winfrm2.cpp(59) : {215}
client block at 0x02E85B30,

...

read more =BB

Thanks for all your help. I have managed to use difference tools of
memory checkpoints to pinpoint the exact source of the problem and
fixed it now.