False memory leak

[wlof]

Hello all,

In order to track and correct memory leaks in my program, I've been using the crtdbg.h tools with the _CRTDBG_MAP_ALLOC symbol defined.

I was able to correct every memory leak. My problem is that the _CrtDumpMemoryLeaks() function launched at application exit still reports two leaks. However, after checking with the step-by-step debugger, I'm sure there is no leak: the destructor for the object where the leaks happen is called and both pointers are delete'd.

It's not really a big problem, but I'd like to know what could cause the function to report memory leaks when there are none. I've tried Googl'ing on the issue but I can't seem to find anything beside's "how to use crtdbg.h" tutorials. Can anyone help?

[wlof]

Actually, I searched a little more and just found a page that says it might be because the object where the false memory leaks happen is static. Is there anything that can be done?

[Codeplug]

You can get false positives due to global object destruction (which happens after main) and other reasons.
http://msdn.microsoft.com/en-us/library/8bsz08tx.aspx

gg

[wlof]

Thank you for the link. I was able to correct those false positives by moving the destructor of my static object in a new method, and calling this method from the destructor and also manually from my application ExitInstance() method (which occurs before the memory leak report is generated). I also added a check to make sure the method isn't called twice unnecessarily. Kinda a lot of work to get rid of a non-problem, but now my app shows no memory leaks at all, which is neat!

[Lindley]

My view is that while it's good to clean up after yourself....if the only reason you've still got heap memory allocated is because the program hasn't exited yet, you're probably fine.

[TheCPUWizard]

My view is that while it's good to clean up after yourself....if the only reason you've still got heap memory allocated is because the program hasn't exited yet, you're probably fine.

A very dangerous mindset to get into. A good program should make sure the destructor is called for every object that is constructed.

Consider:

class Reactor
{
public:
   Reactor()
     {
     }
     void TurnOn()  {}   // Reactor must not be left on or China Syndrome
     void TurnOff()  {}   // Safe once turned off
   ~Reactor()
      {
         TurnOff();
      }
};

int Main();
{
    Reactor*r = new Reactor();
}

You may have just destroyed civilization.

[Lindley]

I would consider that a case worthy of special attention.

Any in any case, the destructor would be called even if it were static, merely after the main() function exits; so that's not really relevant to what I was saying.

[TheCPUWizard]

I would consider that a case worthy of special attention.

Any in any case, the destructor would be called even if it were static, merely after the main() function exits; so that's not really relevant to what I was saying.

Static destructors called after main exits are NOT a problem. (Although they may make analyzing some of the output a bit difficult).

On the otherhand, it is impossible to know if a "leaked" object (ie non-descructed) object at some point in the future may gain a member which holds onto a resource which matters outside the scope of the application. This is a perfect case of Scott Meyers paradigm "Program in the Future Tense".

Additionally, it is easier to develop one consistant set of habits. I write code for everything from military/space/medical/industrial applications where loss of life or millions of dollars may occur in the even of a bug to trivial little utilities. While there (obviously) must be differences in the attention paid to details (in design, implementation, and testing), it really is simpler to apply "best-paractices" accross the board, rather than spend time thinking if I can afford to take shortcuts.

[Lindley]

I don't disagree. My comment was mainly relating to things like singletons which call new internally rather than using the static approach, and the like.

[Martin O]

Thank you for the link. I was able to correct those false positives by moving the destructor of my static object in a new method, and calling this method from the destructor and also manually from my application ExitInstance() method (which occurs before the memory leak report is generated). I also added a check to make sure the method isn't called twice unnecessarily. Kinda a lot of work to get rid of a non-problem, but now my app shows no memory leaks at all, which is neat!

If you're using MFC, then---I think---you don't have to do anything special (like include crtdbg.h or define _CRTDBG_MAP_ALLOC) to see memory leaks if you run your app under the debugger. I think those are defined for you by default in MFC under the debug configuration. Maybe I'm wrong.

If you're not using MFC, there's a command '_CrtSetDbgFlag( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF)' that tells the program to dump leaks at the very end of the program. I used this in a non-MFC app to fix the problem you're describing (false leak due to a static or global, if I remember correctly). But, I think if you use MFC & run the debug config in the debugger (press F5 by default) it should show even memory leaks in static variables & globals. That is...AFAIK

In case you haven't seen it, this leak, oops, link is helpful also:
Visual C++ Debugging: How to manage memory leaks?