Home > Archive > VC Language > June 2005 > Stopping 'false' memory leak traces
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Stopping 'false' memory leak traces
|
|
|
| Does anyone know of any way to stop the false memory leaks that are reported
by the CRT when retail and debug versions of the MFC (shared/DLL) library are
used?
A problem similar to the documented issue:
http://support.microsoft.com/?id=167929
In my case, the client links to the MFC retail version, but the DLL I am
building uses the MFC debug version.
Client => MyDLL_with_dbg_MFC => CRT
|
|===> retail_MFC => CRT
Any static objects declared in my DLL get reported as memory leaks, before
the DLL has unloaded. They are then clearly freed by the CRT when my DLL
unloads.
Can the objects be instructed not to use the leak-tracking mechanism?
TIA.
| |
| Doug Harrison [MVP] 2005-06-09, 4:02 pm |
| On Thu, 9 Jun 2005 01:06:01 -0700, Chard wrote:
> Does anyone know of any way to stop the false memory leaks that are reported
> by the CRT when retail and debug versions of the MFC (shared/DLL) library are
> used?
>
> A problem similar to the documented issue:
> http://support.microsoft.com/?id=167929
>
> In my case, the client links to the MFC retail version, but the DLL I am
> building uses the MFC debug version.
>
> Client => MyDLL_with_dbg_MFC => CRT
> |
> |===> retail_MFC => CRT
>
> Any static objects declared in my DLL get reported as memory leaks, before
> the DLL has unloaded. They are then clearly freed by the CRT when my DLL
> unloads.
>
> Can the objects be instructed not to use the leak-tracking mechanism?
>
> TIA.
I talked about this and gave a workaround for non-MFC DLLs used in MFC apps
in these messages (the first one background, the second workaround):
http://groups-beta.google.com/group...37756da516a8a43
http://groups-beta.google.com/group...33ab8875663cace
As your DLL links to MFC, you may not be able to use this method. Note that
using debug and release MFC DLLs in the same app implies using two
different CRT DLLs as well, so the modules that do this must not expect to
share MFC or CRT state. Rather, they will each have their own private
copies, as if they were little programs unto themselves. This can cause a
world of trouble unless the modules are true black boxes WRT this state.
This means one mustn't use objects such as CWnd* and FILE* created by the
other, one mustn't free memory or delete objects malloc'd or new'd by the
other, and so on.
--
Doug Harrison
Microsoft MVP - Visual C++
|
|
|
|
|