Spurious memory leak reporting

[Doug Harrison]

When a debug mode MFC (VC5) app terminates, MFC reports spurious memory
leaks involving static duration objects that are responsible for allocations
on the heap but haven't yet been destructed. Does anyone know a way around
this? In brief, I have an app that links to the MFC DLL and another DLL "X"
that doesn't use MFC. X defines a static object "x" that maintains a data
structure throughout the program's execution. When the program exits, MFC
reports several hundred false leaks, because x hasn't been destructed. If I
disable leak tracking during construction of x and then restore it, I
partially avoid this problem, but since x takes ownership of pointers to
objects allocated later on in the program's execution, MFC incorrectly
reports those as leaks. While it's extremely undesirable to make any changes
at all to work around this MFC problem, during x's construction, it is
possible and not too onerous, but it's out of the question to modify all the
other client code using x. It's also out of the question for X to link to
MFC to avoid this problem.

It seems to me that automatic leak reporting can only rightfully occur after
destruction of static duration objects and execution of atexit handlers. In
fact, the CRT's automatic reporting seems to do just that. MFC, however,
appears to unconditionally report "leaks" during destruction of its static
duration _AFX_DEBUG_STATE object. The dtor contains the following code (see
mfc/src/DUMPINIT.CPP):

_CrtDumpMemoryLeaks();
int nOldState = _CrtSetDbgFlag(_CRTDBG_REPORT_FLAG);
_CrtSetDbgFlag(nOldState & ~_CRTDBG_LEAK_CHECK_DF);

As far as I can tell, the above code does nothing but create problems. MFC
should allow the CRT to report memory leaks as *it* is shutting down.
Instead, MFC prematurely reports leaks and disables the CRT's automatic leak
reporting. I see no good way around this problem. Any ideas or comments? (To
satisfy my own curiosity, I'd be interested to learn the reason for the
above code's existence.)

--
Doug Harrison
dHar...@worldnet.att.net