mem leaks when using std::map in a dll 
Author Message
 mem leaks when using std::map in a dll

i created a simple MFC window projects with MFC AppWizard.
and created win32 dll. i declared some std::map as global
in a dll. and called several dll functions. ( it means
that i loaded dll )

// IN A WIN 32 DLL
#pragma warning( disable : 4786 )
#include <map>
#include <string>

typedef std::map<std::string, void*> DICT;
DICT g_dict;
...

using Debug Multithreaded project setting is default value
in win32 project. and it's has no problem.
but when i set using Debug Multithread DLL in project
setting, and run the de{*filter*}, it reports memory leak.
when i comment DICT g_dict , then it does not reports
memory leak.

exe was created using Debug Multithreaded DLL setting.(
it's MFC application )

i created only one std::map global variable...

if i do not call any of dll functions, no memory leaks. (
it means dll was not loaded )

i tested with MFC DLL( Debug Multithreded DLL is default
setting ) and it had no problem.

Win32 DLL with Debug Multithreaded setting has no problem.

my questions are...

what is difference between Debug Multithred DLL  and Debug
Multithred setting ???

and why does std::map occur memory leaks in a win32 DLL
using Debug Multithreaded DLL RT library??



Sat, 03 Apr 2004 22:27:17 GMT  
 mem leaks when using std::map in a dll
Hi,

Thanks for using Microsoft products.

This problem only happens when DLL version of the C runtime is used. There
is a difference for STL object when DLL or static version of the c-runtime
is used. For static library, since the STL is implemented as a template, it
is not instantiated until it is referenced. But for DLL version of the
C-runtime, STL objects is explicit instantiated and exported from the DLL,
the static and global objects are allocated when DLL is loaded and are
won't be released until the DLL is unloaded. The de{*filter*} generates the
memory leaks because the MFC DLL is unloaded first, at the time
_CrtDumpMemoryLeak() is called, those memory has not been freed yet which
cause the MFC to report the leak. You can not really control the unloading
sequence of DLL if you are doing implicit linking.

If you use run-time debugging functions, the correct way to detect leak to
set _CRTDBG_REPORT_FLAG so that _CrtDumpMemoryLeak is automatically called
at appropriate time. To do that, add the following lines to the code:
int tmpFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG );
tmpFlag |= _CRTDBG_LEAK_CHECK_DF;

For example. This should be report memory leaks:
void ThisFunctionLeaks()
{      
std::ofstream leakyStream;

Quote:
}

void main()
{
int tmpFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG );
tmpFlag |= _CRTDBG_LEAK_CHECK_DF;
_CrtSetDbgFlag(tmpFlag);
const std::string leakedString = "This string Leaks";
ThisFunctionLeaks();

Quote:
}

Workaround:
1.      Link the DLL with static version of the C-runtime, but that will
increase the DLL size.

2.      Changing the DLL loading sequence. Put the mfc42d.lib in front of your
own DLL in the project settings | Link | Input | Object/module. It will
unload the mfc DLL after your own DLL being unloaded, so the leak will not
be reported. However, it is not very good.

Hope this information helps.

Best Regards,

Bill

This posting is provided "AS IS" with no warranties, and confers no rights.
You assume all risk for your use.

?2001 Microsoft Corporation. All rights reserved.



Fri, 09 Apr 2004 01:24:38 GMT  
 mem leaks when using std::map in a dll

Quote:

> void main()

int main()

Quote:
> {
> int tmpFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG );
> tmpFlag |= _CRTDBG_LEAK_CHECK_DF;
> _CrtSetDbgFlag(tmpFlag);
> const std::string leakedString = "This string Leaks";
> ThisFunctionLeaks();

return 0;

--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)



Fri, 09 Apr 2004 01:59:59 GMT  
 mem leaks when using std::map in a dll


Fri, 19 Jun 1992 00:00:00 GMT  
 mem leaks when using std::map in a dll

Quote:
>-----Original Message-----
>Hi,

>Thanks for using Microsoft products.

>This problem only happens when DLL version of the C

runtime is used. There
Quote:
>is a difference for STL object when DLL or static version
of the c-runtime
>is used. For static library, since the STL is implemented
as a template, it
>is not instantiated until it is referenced. But for DLL
version of the
>C-runtime, STL objects is explicit instantiated and

exported from the DLL,
Quote:
>the static and global objects are allocated when DLL is
loaded and are
>won't be released until the DLL is unloaded. The de{*filter*}
generates the
>memory leaks because the MFC DLL is unloaded first, at
the time
>_CrtDumpMemoryLeak() is called, those memory has not been
freed yet which
>cause the MFC to report the leak. You can not really

control the unloading
Quote:
>sequence of DLL if you are doing implicit linking.

>If you use run-time debugging functions, the correct way
to detect leak to
>set _CRTDBG_REPORT_FLAG so that _CrtDumpMemoryLeak is

automatically called
Quote:
>at appropriate time. To do that, add the following lines
to the code:
>int tmpFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG );
>tmpFlag |= _CRTDBG_LEAK_CHECK_DF;

>For example. This should be report memory leaks:
>void ThisFunctionLeaks()
>{  
>std::ofstream leakyStream;
>}

>void main()
>{
>int tmpFlag = _CrtSetDbgFlag( _CRTDBG_REPORT_FLAG );
>tmpFlag |= _CRTDBG_LEAK_CHECK_DF;
>_CrtSetDbgFlag(tmpFlag);
>const std::string leakedString = "This string Leaks";
>ThisFunctionLeaks();
>}

>Workaround:
>1.  Link the DLL with static version of the C-runtime,
but that will
>increase the DLL size.

>2.  Changing the DLL loading sequence. Put the

mfc42d.lib in front of your
Quote:
>own DLL in the project settings | Link | Input |

Object/module. It will

- Show quoted text -

Quote:
>unload the mfc DLL after your own DLL being unloaded, so
the leak will not
>be reported. However, it is not very good.

>Hope this information helps.

>Best Regards,

>Bill

>This posting is provided "AS IS" with no warranties, and
confers no rights.
>You assume all risk for your use.

>?2001 Microsoft Corporation. All rights reserved.

>.



Sat, 10 Apr 2004 02:23:03 GMT  
 
 [ 5 post ] 

 Relevant Pages 

1. Mem leaks with small ATL DLL using CDatabase

2. Mem leaks using CDatabase in ATL DLL

3. Mem leaks with small ATL DLL using CDatabase

4. Passing std::set and std::map objects between 2 dlls

5. Memory leak? (std::map, VC7)

6. export classes using std namespace (ex std::vector) in a DLL

7. Mem Leaks with ATL DLL and CDatabase

8. dll mem leak

9. Exporting STL containers (specifically std::map) from DLL?

10. Error using Microsoft's implementation of std::map

11. Having problems with using std::map

12. Using the class in the std::map inside the definition of class itself

 

 
Powered by phpBB® Forum Software