False memory leak

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?

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?

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

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! :)

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.

Quote:

---

Originally Posted by 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.

---

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

Consider:

Code:

---

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.

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.

Quote:

---

Originally Posted by 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.

---

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.

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.

Quote:

---

Originally Posted by 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! :)

---

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?