VS2010 reports false memory leaks for static classes in a DLL

Question

A follow-up question to Memory leaks when calling ITK from Visual Studio DLL

I refined the problem to the simplest example.

struct A
  {
  public:
    A()
      {
      mp_data = new int(0x42);
      }
    ~A()
      {
      delete mp_data;
      }
    int* mp_data;
  };

A a;

When such a global class is defined in a DLL, Visual Studio debug CRT reports that mp_data is leaked on application shutdown. Does anybody know a workaround except disabling leak reporting?

This might be a Visual Studio bug. See the comments under the accepted answer [here](http://stackoverflow.com/questions/2204608/does-c-call-destructors-for-global-and-class-static-variables). — Frédéric Hamidi, Apr 24 '12 at 14:30
No, that's not the reason. I've verified in the debugger that `~A()` is really called. — Andriy, Apr 24 '12 at 14:34

score 5 · Accepted Answer · edited Mar 26 '20 at 11:26

If you are calling _CrtDumpMemoryLeaks() at the end of the main function the behaviour is expected, since mp_data will be deleted after _CrtDumpMemoryLeaks() was called.

You would need to call _CrtDumpMemoryLeaks() after the last destructor of you static objects has been called (or rather in the last destructor after the memory has been freed) if you don't want to see these leaks (quite a difficult task, I wouldn't try it).

The cleaner approach is to allocate all your static objects on the heap instead (at the beginning of main), and de-allocate them at the end of main, and then you can call _CrtDumpMemoryLeaks() and won't see any memory leaks.

FYI static objects with constructors and destructors are considered bad anyways, because the order in which they are constructed/destructed is not deterministic, and because of that static objects often introduce bugs which can't be debugged easily.

Edit regarding Andrey's comment: You could try to deactivate the automatic call to _CrtDumpMemoryLeaks by calling _CrtSetDbgFlag to unset the _CRTDBG_LEAK_CHECK_DF flag. If that works, you can add a static object which calls _CrtDumpMemoryLeaks() in its destructor. To make sure that this object is destructed last, you can use the #pragma init_seg(compiler) directive.

No clue if this will work... Other than that, all other solutions will most likely require you to modify the ITK library (which should be possible, it's an open source library after all?!).

That's not quite applicable, because (1) I don't call _CrtDumpMemoryLeaks() myself, VS runtime library does that for me; (2) in fact, static objects are in a 3rd party lib which is outside my control (follow the link in the question) — Andriy, Apr 25 '12 at 06:22

score 2 · Answer 2 · answered Apr 25 '12 at 09:40

Any of following solves the problem.

(1) Create a fake dependency of the DLL on MFC, or

(2) Use the solution suggested by smerlin: add this code next to DllMain

struct _DEBUG_STATE
  {
  _DEBUG_STATE() {}
  ~_DEBUG_STATE() { _CrtDumpMemoryLeaks(); }
  };

#pragma init_seg(compiler)
_DEBUG_STATE ds;

score 2 · Answer 3 · answered Feb 05 '14 at 18:23

I hit the same symptom in the course of migrating an internal library from static linking to load-time dynamic linking, and it turned out that the problem in my case was that the DLL project and the EXE project were linked to different versions of VC++'s runtime/MFC libraries (one was MBCS and one was Unicode).

In my case, the application and library were both using MFC, and the _AFX_DEBUG_STATE destructor which activates the CRT memory leak dump was being called twice, for two separate objects -- since the DLL and EXE linked to different runtime DLLs, static state in the runtime was effectively duplicated. One of the DLLs would unload and dump leaks too early and show a bunch of false leaks. Switching both projects to use the same character set resolved the separate runtime linkage and also resolved the false leak reports.

In my case, linkage to the two separate runtimes was unintentional and may have caused other problems anyway. This obviously wouldn't be the case when consuming third party libraries with a well-defined ABI where you have no control over what CRT the library is linked to.

Not sure if this would've be applicable in your case but I wanted to post in case it's helpful to others.

helb · Answer 4 · 2015-08-27T07:00:11.717

0

In MFC applications you can disable automatic memory leak dump by calling:

AfxEnableMemoryLeakDump(FALSE);

This is supported since Visual Studio 2010. For the documentation, see here.

edited Aug 27 '15 at 07:00

answered Aug 24 '15 at 15:31

helb

7,609
8
36
58

score 0 · Answer 5 · edited May 23 '17 at 12:17

I had the same problems in Visual Studio 2015. I tried all the solutions. The first solution with fake-MFC-dependency only worked if you choose compiler option /MT in your Dll. So your Dll and main application won't share the same heap. But often /MD is needed, e.g. if you want to share STL container or string objects between the Dll and your main application (Dll-boundary). If /MD is used, app and Dll use the same heap. So the first solution with fake-MFC-dependency didn't work for me.

I don't like the second solution by disabling memory-leak-detection in the main application. When you don't need the Dll with this call in destructor anymore, you have to remember to reactivate the memory-leak-detection in your application.

I found another solution so I didn't have false-memory-leaks anymore. You only have to use the /delayload linker option for your Dll! That's all :-). It worked for me also with compiler option /MD.

Here you can read something about Dll-boundary (why to use /MD?). And here you can read something about CRT compiler options in general.

VS2010 reports false memory leaks for static classes in a DLL

5 Answers5

Linked