MFC memory leaks when unloading DLL

John W. Podlogar Jr. -- podlogar@telerama.lm.com
Wednesday, April 10, 1996


Greetings...

Environment MSVC 4.1, NT 4.0 Beta 1, Intel, SDI application

I'm writing a "regular" DLL (USRDLL) that uses MFC in a DLL (not statically
linked). Everything is working great except for when I unload
the DLL. MFC and the debugger are reporting some memory leaks
in various MFC source files. They are reported when my overridden
CWinApp::ExitInstance() is run by the framework.

I've been searching through the online doc and the kb at Microsoft
and found some articles relating to use of the CRT WEP procedure.
This however doesn't seem to work as stated anymore (it's kind of
and old article). It appears that the destructors aren't
being called for internal MFC static and global data.

Since I am kind of anal about memory leaks I'd really like to
get the DLL to unload cleanly. Does anybody have any ideas?

Thanks -John

Below is the output from the debugger...

Detected memory leaks!
Dumping objects ->
plex.cpp(31) : {49} normal block at 0x00C32450, 124 bytes long.
 Data: <             "  > 00 00 00 00 00 00 00 00 00 00 00 00 F0 22 C3 00 
doctempl.cpp(64) : {48} client block at 0x00C323F0, subtype 0, 32 bytes long.
a CDocManager object at $00C323F0, 32 bytes long
doctempl.cpp(62) : {47} client block at 0x00C32398, subtype 0, 28 bytes long.
a CPtrList object at $00C32398, 28 bytes long
Object dump complete.

John W. Podlogar Jr.    The wise man doesn't pose the right answers, 
podlogar@lm.com                         he asks the right questions. 
http://www.lm.com/~podlogar

---

Mike Blaszczak -- mikeblas@msn.com
Sunday, April 14, 1996

[Mini-digest: 3 responses]

> Environment MSVC 4.1, NT 4.0 Beta 1, Intel, SDI application

Thanks.

> It appears that the destructors aren't
> being called for internal MFC static and global data.

They are.  It looks like these bugs are yours, not MFC's.

> plex.cpp(31) : {49} normal block at 0x00C32450, 124 bytes long.

This object is normally used to manage items in an MFC collection.  You can 
get leaks with this signature if you don't correctly clean up a linked list or 
a map or an MFC array.

> doctempl.cpp(64) : {48} client block at 0x00C323F0, subtype 0, 32 bytes 
long.
> doctempl.cpp(62) : {47} client block at 0x00C32398, subtype 0, 28 bytes 
long.

These two mean that you're leaving a CDocTemplate around.  Are you creating 
your own, extra CDocTemplate?  You'll get these leaks if you create your own, 
don't register it with MFC, and don't clean it up yourself.  Taken together, 
it looks like there's a chance the whole doc template chain isn't being 
destroyed since the list itself _and_ its content aren't being destroyed.  You 
say that you've overridden ExitInstance()--did you call the base class 
implementation?

.B ekiM
TCHAR szSpringtime[] = _T("Check twice and save a life: motorcycles are 
everywhere.");

-----From: "Matt Gradwohl" 

I'm not sure about these specific leaks, but I know that some MFC "leaks" 
aren't really leaks. There is, or soon will be, a knowledgebase article on 
this.

*** Foggy memory, talking out rear-end == ON ***
Something to do with the leak checking code not taking into account the 
destructor throwing the memory away
*** Foggy memory, talking out rear-end == OFF ***

So, basically, it's good that you are anal about memory leaks, but some of 
these MAY be false (wait for the KB article. Then again, if it's only 28 + 28 
+ 32 +124 bytes each time your APP runs, and you don't allow multiple 
instances of your app, the leak, although bad, shouldn't cause too much bad 
mojo.

-Matt
http://hellbender/mattgr/ <--sucks
http://hellbender/project/grunt/

-----From: Randal Parsons 

It seems that the memory leak detection can't tell when static/global 
data is destructed because of the mechanism it uses (which is itself 
based around global/static data I think). We have had the same problem 
since we started using Objectspace STL because it contains static 
allocators, so we traced the memory allocations that were 
identified as leaks and just ignored the ones that were for global data.

Regards,

Randal Parsons.

---

| Вернуться в корень Архива |