Re: Missing destructor calls on exit

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

From: Nathan Holt (nathanh_at_ccei-nm.com)
Date: 04/19/04 

Date: Mon, 19 Apr 2004 09:46:31 -0600

"HeroOfSpielburg" <ventudg@hotmail.com> wrote in message
news:ff4d2e3a.0404150338.333de6e6@posting.google.com...
> Sorry if this is well covered ground, but many of the tactics I tried
> to employ from other threads didn't pan out (and most importantly
> allow me to understand _why_ this is happening).
>
> I have a doc/view mdi app. My runtime library is multi-threaded debug
> DLL. On exit of the application (via file..exit or the X button), I
> get a bunch of memory leaks. Some from a modeless dialog (whose
> destructor is not called), the CMainFrame itself (all 2K), the
> CDocManager, CMultiDocTemplate, and a CCmdTarget (these are created by
> the CWinApp I believe). A breakpoint gets hit in my CMainFrame (which
> happens to be the parent of the modeless dialog) destructor, but for
> some reason I still have that 2K of memory lost. It looks like the
> bulk of the memory allocated by the app is not getting put away, all
> that stuff in InitInstance(). As for the modeless dialog, perhaps
> that's a separate issue.

    Something could be throwing an exception in the destructor, which might
well abort the destruction process but still allow your program to exit.
Try steping through the destructor to find what goes wrong.

> As for the modeless dialog, I read in another thread that the
> "preferred" way to get rid of a modeless dialog gracefully was to
> override OnNcDestroy and call "delete this", in conjuction with
> ON_WM_CLOSE and call "DestroyWindow". This, however, resulted in a
> crash via RtlValidateHeap(x,x). I suspect, however, that is may be
> because the modeless dialog uses a custom object, a PropTree, which
> happens to have its code in a DLL I link to. Because this DLL is
> separate from the main code, is it living in another heap and I can't
> get rid of it from the application?

    Having objects delete themselves like that is a dangerous idea. In
order for it to work, you need to provide some means of seting all the
pointers to the object to NULL in the objects destructor, otherwise you end
up with wild pointers to where the object was. It's usually simpler to
delete the object from code that has easy access to the pointers. The
documents and views that MFC uses have a bit of machinery to get away with
the auto delete technique.
    The other dll might or might not have a seperate heap. If it does have
a seperate heap, it should provide functions to deallocate the prop tree
safely. I'd look at your documentation to see how the PropTree object
should be deallocated.

> I know these are a lot of questions, and the solution may seem
> obvious, but I've been beating my head and don't know what's expected
> or normal in these situations. LIke I said, the solution doesn't
> matter to me so much as understanding why this is happening in the
> first place. (Probably something I messed up/overrode.) Much thanks
> in advance for the help.

    You're welcome. I hope this helps.

                                        Nathan Holt

Quantcast