|
Probably, except for pressing the keyboard it is necessary to control the clicks of the mouse. Yes a task not easy.
I shall try, time is not present a way easier, it to realize.
Many thanks for the numerous help to me, including this.
Best regards,
Eugene Pustovoyt
|
|
|
|
|
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 />
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),
RUNTIME_CLASS(CExplorerView));
whats going on have i gone mad?!?
Asim Hussain
e: asim@jawache.net
w: www.jawache.net
|
|
|
|
|
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. **
|
|
|
|
|
I did check on all the ones i declared myself that and it yes they are called. 
Does IMPLEMENT_DYNACREATE declare some memory aswell, if so where is it deleted?
Asim Hussain
e: asim@jawache.net
w: www.jawache.net
|
|
|
|
|
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. **
|
|
|
|
|
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
|
|
|
|
|
Go one level up and put the bkpt in CWinApp::~CWinApp.
Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
|
|
|
|
|
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.
|
|
|
|
|
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
|
|
|
|
|
You are not using global instances of MFC classes?
Global instances destructors are called after reporting memory leaks.
Pavel
Sonork 100.15206
|
|
|
|
|
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
|
|
|
|
|
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. **
|
|
|
|
|
It is called and m_pDocManager is NULL !
Asim Hussain
e: asim@jawache.net
w: www.jawache.net
|
|
|
|
|
Can you check m_pDocManager at the end of CYourApp::InitInstance?
Tomasz Sowinski -- http://www.shooltz.com
** Putt knot yore thrust inn spel chequers. **
|
|
|
|
|
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
|
|
|
|
|
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. **
|
|
|
|
|
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
|
|
|
|
|
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. **
|
|
|
|
|
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
|
|
|
|
|
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. **
|
|
|
|
|
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
|
|
|
|
|
_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
|
|
|
|
|
its declared in dllole.cpp
Asim Hussain
e: asim@jawache.net
w: www.jawache.net
|
|
|
|
|
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
|
|
|
|
|
I reckon they are.. i'll contact the author.
Should it matter though, I thought the whole COM ActiveX thing was entirely self contained i.e. it shouldn't matter what they are written in as long as they have the same interface.
So basically, CExplorerApp theApp; is not being destroyed. So VC is picking up memory leaks.
There must be an error after the destruction of _afxOleWinApp before theApp can be destroyed.
Asim Hussain
e: asim@jawache.net
w: www.jawache.net
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
