Finding the elusive memory leak...

Now I have a project, which is in total 4-5k lines of code, and am now leaking 24 bytes one time when I close. I've narrowed down the size to a custom struct I made. However, for all you debugging junkies out there, is it a good idea to go on this memory size as reported by MSVC 2003 .net? Or is this only a small guide to let me know there is a leak somewhere. I know this is a rather nebulous question but any theories would be helpful.

You can use the functionality provided by visual studio inside of crtdbg.h

Here is a link:
http://www.thinkingms.com/pensieve/h...orld_debug.htm

Simple and effective. If you have the money to throw around I strongly recommend BoundsChecker.

Hm I've never used crtdbg.h before. I tried that out and it seems that it flags memory leaks for classes that cleanup in their destructor (like std::vector) I guess that makes sense, but what's the best way to deal with that? Maybe just explicitly calling the destructor before _CrtDumpMemoryLeaks(); ...?

Quote:

---

Originally Posted by JaWiB

Hm I've never used crtdbg.h before. I tried that out and it seems that it flags memory leaks for classes that cleanup in their destructor (like std::vector) I guess that makes sense, but what's the best way to deal with that? Maybe just explicitly calling the destructor before _CrtDumpMemoryLeaks(); ...?

---

Make sure everything is destructed by the time _CrtDumpMemoryLeaks() is called by removing global variables, introducing an extra scope, moving code to a separate function, or whatever you need to do. Don't explicitly call the destructor, though.

well,

this is very imp info regarding memory leaks.

thanks for this.

and keep it up.