MFC Crash on exit

Something that others may have overlooked is your destructors.

Make sure your derived class destructors are declared virtual so the base class destructors are correctly called.

As a general rule, I make all of my destructors virtual so that I don't run into this type of problem.

So, in short, change all of your class destructors to virtual, and see what happens.

Hope this helps,

- Nigel

Quote:

---

Originally Posted by NigelQ

As a general rule, I make all of my destructors virtual so that I don't run into this type of problem.
- Nigel

---

Really, even classes which are not used polymorphically?

Thanks for the tip nigel, but I'm pretty sure all of my classes that need it have virtual destructors.

However, I seem to have made a breakthrough, at least it seems to prevent the crash some of the time. In my CView derived class, if I add this:

Code:

---

        if(GetMainWnd()->GetActiveView() == this)
                GetMainWnd()->SetActiveView(NULL);

---

in the destructor, it doesn't crash every time I exit.
(GetMainWnd() just casts the result of AfxGetMainWnd() to a CMDIFrameWnd)

This doesn't make any sense to me. Shouldn't MFC's CView destructor be doing this for me? I have a feeling this is just covering up another problem.

A complete stack trace with symbols can also help people give you hints. Use the symbol server, if you do not have .NET then you need to grab windbg or if you installed the debugging tools for the Platform SDK then it should be in one of it's install dirs.

http://msdn.microsoft.com/library/de...mbolserver.asp

http://msdn.microsoft.com/library/de...g_debugger.asp

Also make sure there is nothing getting sent to the debug output window...Like 'heap errors' etc.

Hmm, I wonder if you're trying to access one of the view(s) during the shutdown process, which is accessing some invalid memory. Could you set a flag once the shutdown has been issued and see if your OnUpdate handlers are being called after the flag is set? Also check anything outside the views that might be indirectly accessing a view.

souldog, you're right, the virtual destructors are not needed unless the class is referenced in a polymorphic way, but there are instances when this type of access is difficult to spot.

If we look at the example of Kibble here, if his derived view's destructor is not declared virtual, all kinds of problems exist when the view and main frame objects are being cast and recast to other types. As a rule yes, I still try to make all of my destructors virtual to avoid the issue - I'll live with the added expense.

- Nigel

Unfortuantely I'm using Visual Studio 6, I'm downloading the part of the SDK with windbg now.

Quote:

---

if his derived view's destructor is not declared virtual

---

It is, and has to be, because CObject's destructor has got to be virtual.

Nothing is showing up in the output window, except of course the Access Violation.

Quote:

---

Hmm, I wonder if you're trying to access one of the view(s) during the shutdown process, which is accessing some invalid memory. Could you set a flag once the shutdown has been issued and see if your OnUpdate handlers are being called after the flag is set? Also check anything outside the views that might be indirectly accessing a view.

---

This is most likely my problem, however I'm fairly sure that I'm not doing it. I can check more, but I can't think of anything of mine that would be doing that. Could it be that I'm not destroying something where I should be? edit: Of course it could be, but is there something that I need to destroy? I kind of assumed MFC would destory the document and view on exit.

Sorry about all of this I'm a bit of an MFC newbie, just trying to make an editor for my game engine.

OK! I have discovered the cause of the crash. I was handling WM_SETFOCUS, which looked like this:

Code:

---

void CRtsEdView::OnSetFocus(CWnd * pOldWnd)
{
    CView::OnSetFocus(pOldWnd);

    GetMainWnd()->SetActiveView(this);
}

---

HOWEVER, apparently that code was necessary to maintain the active view (is the active view member of CFrameWnd not maintained by MFC, I have to maintain it?). Now some of my UI elements don't function properly because they depend on the active view being set to the correct view. I suppose I could try to handle OnKillFocus as well and SetActiveView(NULL) in that handler, if the active view is 'this'. This all seems pretty hackish to me though, shouldn't the CFrameWnd/CMDIFrameWnd be maintaining this member?

Alright, sorry for so many posts. I seem to have solved it by simply maintaining my own active view and document pointers, and not ever calling the SetActiveView MFC member function. I assume MFC was trying to do something with this pointer, yet it doesn't maintain it? that seems pretty obnoxious to me, I must be doing something else wrong.

Quote:

---

Originally Posted by NigelQ

If we look at the example of Kibble here, if his derived view's destructor is not declared virtual, all kinds of problems exist when the view and main frame objects are being cast and recast to other types. As a rule yes, I still try to make all of my destructors virtual to avoid the issue - I'll live with the added expense.
- Nigel

---

Correct me if I am wrong, but if the base class has a virtual destructor then any derived class will have an implied virtual destructor, even if you don't explicitly declare
it that way. In other words it does not matter if you don't declare the destructor
virtual, although it is good documentation.

You know, I have been coding for 10 yrs now, I never use debug or diagnostic tools, why, because in C++ it's usually a memory problem.

What I have found works great for debugging and how I debug is I use:

CString msg
msg.Format (" Accessing code sectiong %s, %d, %c", somestring, someint, somechar);
AfxMessageBox(mst);


.. and I place messageboxes and track variable till I find where the code starts hanging, then fix the problem.

Obvioulsy some pointer is not accessedd properly, or some device context is not being released.

Use AfxMessageBox, and track down where the code executes properly just before bombing then you can breakit down better.


... hope that helps.

Quote:

---

Originally Posted by souldog

Correct me if I am wrong, but if the base class has a virtual destructor then any derived class will have an implied virtual destructor, even if you don't explicitly declare
it that way. In other words it does not matter if you don't declare the destructor
virtual, although it is good documentation.

---

You are right, not just destructors but all virtual functions. In this case, CObject has a virtual destructor, which CView is a descendant of.

Quote:

---

Originally Posted by Kibble

Alright, sorry for so many posts. I seem to have solved it by simply maintaining my own active view and document pointers, and not ever calling the SetActiveView MFC member function. I assume MFC was trying to do something with this pointer, yet it doesn't maintain it? that seems pretty obnoxious to me, I must be doing something else wrong.

---

I have to say that I do the same thing, I manage the views myself, although I am using a SDI application with several views. (I always just ignore the document
anyway)

Oh and if you are using an MDI, then I think you want to be using
MDIActivate(CMDIChildWnd* blah);

So you activate the child frame window.

I think the framework will keep track of the active view for you

Quote:

---

Originally Posted by ADSOFT

You know, I have been coding for 10 yrs now, I never use debug or diagnostic tools, why, because in C++ it's usually a memory problem.

.

---

You probably shouldn't be admitting that.
;) :D

Quote:

---

Originally Posted by ADSOFT

You know, I have been coding for 10 yrs now, I never use debug or diagnostic tools, why, because in C++ it's usually a memory problem.

What I have found works great for debugging and how I debug is I use:

CString msg
msg.Format (" Accessing code sectiong %s, %d, %c", somestring, someint, somechar);
AfxMessageBox(mst);

---

These things may have helped you, but they are not recommended for debugging memory related issues and window procedure/messaging issues.

1) The CString class allocates memory. If you've corrupted the heap before you declare the CString, you are accessing an invalid heap to create the CString.

2) AfxMessageBox() -- If you are having an issue with messaging in your window procedure, AfxMessageBox() (or even the API MessageBox) function may invoke behavior of your application that is undesired.

To circumvent both these problems, you may want to use a locally defined char buffer, sprintf(), and use OutputDebugString instead of AfxMessageBox.

Code:

---

{
  char sz[100]; // or whatever you feel is large enough for your message
  sprintf(sz, "%d", whatever);
  OutputDebugString( sz ):
}

---

This is what I use, and has the least impact on a possible memory access bug or messaging issue.

Regards,

Paul McKenzie