C / C++ / MFC

9-Sep-02 1:12

I seem to have started to generate memory leaks,

really frustrating ones. I think something very strange is going on.

For Example:
in my Splitter class i declare a sub splitter,

m_pwndSplitter = new CJEXSplitter;

it says this is the source of the memory leak but i definately delete it in the destructor:

CJEXSplitter::~CJEXSplitter()<br />
{<br />
	// Get Window Sizes and Store in Registry<br />
	int iTemp = 0;<br />
	GetColumnInfo(0,m_szFromLeft,iTemp);<br />
	m_pwndSplitter->GetRowInfo(0,m_szFromTop,iTemp);<br />
	CWinApp * pApp = AfxGetApp();<br />
	pApp->WriteProfileInt(_T("SPLITTER"),_T("FROMLEFT"),m_szFromLeft);<br />
	pApp->WriteProfileInt(_T("SPLITTER"),_T("FROMTOP"),m_szFromTop);<br />
<br />
<br />
<br />
	if (m_pwndSplitter) <br />
		delete m_pwndSplitter;<br />
<br />
}

but then it starts saying i have other memory leaks in places I haven't touched like
in my CMainFrame class at
IMPLEMENT_DYNCREATE(CMainFrame, CUIMainFrame)
and in my document class
IMPLEMENT_DYNCREATE(CExplorerDoc, CDocument)

the killer for me is that it says theres a memory leak here to:-

pDocTemplate = new CSingleDocTemplate(<br />
    IDR_MAINFRAME,<br />
    RUNTIME_CLASS(CExplorerDoc),<br />
    RUNTIME_CLASS(CMainFrame),       // main SDI frame window<br />
    RUNTIME_CLASS(CExplorerView));

whats going on have i gone mad?!?

Asim Hussain
e: asim@jawache.net
w: www.jawache.net

Tomasz Sowinski9-Sep-02 1:25

9-Sep-02 1:25

Looks like your program is terminated prematurely. Can you put the breakpoint in CYourApp destructor and check if it's actually executed?

Tomasz Sowinski -- http://www.shooltz.com

** Putt knot yore thrust inn spel chequers. **

Jawache9-Sep-02 1:39

9-Sep-02 1:39

I did check on all the ones i declared myself that and it yes they are called. Confused | :confused:

Does IMPLEMENT_DYNACREATE declare some memory aswell, if so where is it deleted?

Asim Hussain
e: asim@jawache.net
w: www.jawache.net

Tomasz Sowinski9-Sep-02 1:46

9-Sep-02 1:46

Jawache wrote:
Does IMPLEMENT_DYNACREATE declare some memory aswell, if so where is it deleted?

Not really. IMPLEMENT_DYNCREATE provides the functionality of IMPLEMENT_DYNAMIC (MFC's own, primitive form of RTTI) and adds trivial implementation of virtual function CreateObject.

CreateObject is used by the framework to create documents/views/frames. If you see leaks originating in CYourObj::CreateObject, then something is wrong with app cleanup. Or - maybe you're playing tricks with doc/view architecture.

Tomasz Sowinski -- http://www.shooltz.com

** Putt knot yore thrust inn spel chequers. **

Jawache9-Sep-02 2:09

9-Sep-02 2:09

I've managed to find and put a breakpoint in CDocManager::~CDocManager()

and it isn't called!!!!

I've also just noticed in the debug window:-

ASSERT_VALID fails with NULL pointer. <- HUH??
The thread 0x46C has exited with code 3 (0x3). <-- Hmmm...
Detected memory leaks!

Asim Hussain
e: asim@jawache.net
w: www.jawache.net

Tomasz Sowinski9-Sep-02 2:11

9-Sep-02 2:11

Go one level up and put the bkpt in CWinApp::~CWinApp.

Tomasz Sowinski -- http://www.shooltz.com

** Putt knot yore thrust inn spel chequers. **

Roger Allen9-Sep-02 1:49

Roger Allen

9-Sep-02 1:49

Are you using serialization on some of these objects? If you are then you can get memory leaks by using serialization with pointers like this.

CMyObject *pObject = new CMyObject ;

archive >> pMyObject ; // leak! as CObject create a new object losing the earlier allocated object.
This can be seen in the debugger by stepping over the seriazation line and seeing that the pMyObject pointer value changes.

Roger Allen
Sonork 100.10016

I think I need a new quote, I am on the prowl, so look out for a soft cute furry looking animal, which is really a Hippo in disguise. Its probably me.

Jawache9-Sep-02 1:56

9-Sep-02 1:56

Nope, nothing.

Unless the Document or WinApp performs serialization by itself, but i would imagine I would have noticed the memory leaks earlier.

Asim Hussain
e: asim@jawache.net
w: www.jawache.net

Pavel Klocek9-Sep-02 1:52

Pavel Klocek

9-Sep-02 1:52

You are not using global instances of MFC classes?
Global instances destructors are called after reporting memory leaks.

Pavel
Sonork 100.15206

Jawache9-Sep-02 1:59

9-Sep-02 1:59

Nope,

I'm using a number of singleton classes but they aren't the ones with the memory leaks and anyway i use static variables for the instances not pointers.

Whats really confusing me is that VC is saying i have a memory leak in my App::InitInstance where I register the document templates,

pDocTemplate = new CSingleDocTemplate( there is no way that should be the cause of a memory leak because that is part of the framework.

Asim Hussain
e: asim@jawache.net
w: www.jawache.net

Tomasz Sowinski9-Sep-02 2:07

9-Sep-02 2:07

Document template is deleted by CDocManager destructor. CDocManager is an internal MFC class. Can you put breakpoint in CWinApp::~CWinApp - it's appcore.cpp file in mfc\src, at least in VC6. You should see the following code:

if (m_pDocManager != NULL)
	delete m_pDocManager;

Maybe for some reason m_pDocManager is NULL?

Tomasz Sowinski -- http://www.shooltz.com

** Putt knot yore thrust inn spel chequers. **

Jawache9-Sep-02 2:13

9-Sep-02 2:13

It is called and m_pDocManager is NULL !

Asim Hussain
e: asim@jawache.net
w: www.jawache.net

Tomasz Sowinski9-Sep-02 2:19

9-Sep-02 2:19

Can you check m_pDocManager at the end of CYourApp::InitInstance?

Tomasz Sowinski -- http://www.shooltz.com

** Putt knot yore thrust inn spel chequers. **

Jawache9-Sep-02 2:22

9-Sep-02 2:22

Yup,

Its declared in AddDocTemplate

and its still NOT null by the end of InitInstance()

Asim Hussain
e: asim@jawache.net
w: www.jawache.net

Tomasz Sowinski9-Sep-02 2:26

9-Sep-02 2:26

Jawache wrote:
and its still NOT null by the end of InitInstance()

This is how it's expected to work.

Now, the advanced breakpoint stuff. Open the breakpoints dialog box (Ctrl+B), select the 'Data' tab and type 'theApp.m_pDocManager' (without apostrophes) in the 'Enter the expression to be evaluated' box. Run the program - you should hit the bkpt in the InitInstance first (this is when it's initialized), then for the second time when it gets nullified.

Tomasz Sowinski -- http://www.shooltz.com

** Putt knot yore thrust inn spel chequers. **

Jawache9-Sep-02 2:39

9-Sep-02 2:39

Argh....

The breakpoint is called when the m_pDocManager is initiated but isn't when it goes back to NULL?? -- Hmm.. soounds like VC itself is buggered...

Asim Hussain
e: asim@jawache.net
w: www.jawache.net

Tomasz Sowinski9-Sep-02 2:43

9-Sep-02 2:43

Jawache wrote:
The breakpoint is called when the m_pDocManager is initiated but isn't when it goes back to NULL

Well, it never goes back to NULL in correctly behaving app. CWinApp::~CWinApp just deletes m_pDocManager. But you're sure that at this point m_pDocManager is NULL when your app exits?

Tomasz Sowinski -- http://www.shooltz.com

** Putt knot yore thrust inn spel chequers. **

Jawache9-Sep-02 2:53

9-Sep-02 2:53

Yes,

It's definately null by the time the destructor is called, but the conditional breakpoint isn't called.

Does the advanced breakpoint work if its a memory overwrite ?

Interesting point -- I put a breakpoint in the connstructor and its actually called twice? I thought there was only ever 1 CWinApp derived object.

Asim Hussain
e: asim@jawache.net
w: www.jawache.net

Tomasz Sowinski9-Sep-02 2:55

9-Sep-02 2:55

Jawache wrote:
I put a breakpoint in the connstructor and its actually called twice? I thought there was only ever 1 CWinApp derived object

Yes, there should be exactly one CWinApp-derived object. Look at the call stack when code hits the breakpoint in constructor.

Tomasz Sowinski -- http://www.shooltz.com

** Putt knot yore thrust inn spel chequers. **

Jawache9-Sep-02 3:36

9-Sep-02 3:36

The first CWinApp Derived is

CWinApp _afxOleWinApp;

the second is the normal

CExplorerApp theApp;

I think its safe at this point to mention that i'm using some activeX controls in my applications. I suppose thats what the _afxOleWinApp is all about.

The constructor is called twice becuase two objects are created, but the destructor is called once.

I think i've got it.

The descructor is called for _afxOleWinApp and since no documents have been added to this one the m_pDocManager is NULL by the time the destructor is called.

This must cause some error and the app to terminate incorrectly.

What is _afxOleWinApp is this correct behavior, to have 2 WinApps?

Asim Hussain
e: asim@jawache.net
w: www.jawache.net

Tomasz Sowinski9-Sep-02 3:49

9-Sep-02 3:49

_afxOleWinApp is defined in dll-related MFC source files. The comment next to declaration states that '// This CWinApp is required so this module state has a CWinApp object!'

It seems you're somehow managed to mix dll-mode MFC into your .exe. Is _afxOleWinApp declared in dllinit.cpp or dllole.cpp?

Tomasz Sowinski -- http://www.shooltz.com

To some its a six-pack, to me it's a support group

Jawache9-Sep-02 4:08

9-Sep-02 4:08

its declared in dllole.cpp

Asim Hussain
e: asim@jawache.net
w: www.jawache.net

Tomasz Sowinski9-Sep-02 4:12

9-Sep-02 4:12

Jawache wrote:
its declared in dllole.cpp

Maybe your ActiveX controls are MFC-based?

Tomasz Sowinski -- http://www.shooltz.com

To some its a six-pack, to me it's a support group

Jawache9-Sep-02 4:33