memory leak detection in unmanaged C++ MFC code
-
What's the latest best approach to finding memory leaks in unmanaged C++ MFC code? I've read about LeakDiag but the latest version of that is a bit old (which leads me to guessing its not maintained anymore). I have a case where I get persistent memory growth after an operation. I do the operation which loads a bunch of data, then I free it all, and at the end my memory usage is up a bit from where it was before I loaded the data. I'm looking at Private Bytes and Working Set in Process Explorer and my app uses directly the Windows Heap APIs as well as CRT new/delete for allocating/freeing memory. I ran in the debugger (I'm using VS2005) and it didn't complain about any leaks as it sometimes does when you have leaks.
The best approach isn't to leak any memory, then you don't have any leaks to find. So instead of using raw pointers use a wrapped pointer of some sort, instead of dynamically allocated arrays use std::vector. The moral is if you don't manually manage it you can't leak it. Cheers, Ash
-
One way is to get a demo of BoundsChecker. There's WinDbg (shudder) Right here on CodeProject, there's Visual Leak Detector. Visual Leak Detector - Enhanced Memory Leak Detection for Visual C++[^] & Memory(-Leak) and Exception Trace (CRT and COM Leaks)[^] Also ran across this, but I know almost nothing about it and haven't tried it: http://valgrind.org/[^] (Small FYI; I tried AQTime a year or so ago and hated it, but to each his own.)
About Visual Leak Detector, you'd better try the most recent versions @ codeplex : http://vld.codeplex.com/ (pre-emptive WTF, the clicky thing stopped working in Safari?!?!)
Watched code never compiles.
-
One way is to get a demo of BoundsChecker. There's WinDbg (shudder) Right here on CodeProject, there's Visual Leak Detector. Visual Leak Detector - Enhanced Memory Leak Detection for Visual C++[^] & Memory(-Leak) and Exception Trace (CRT and COM Leaks)[^] Also ran across this, but I know almost nothing about it and haven't tried it: http://valgrind.org/[^] (Small FYI; I tried AQTime a year or so ago and hated it, but to each his own.)
Thanks for the links! I'll take a look at those.
-
The best approach isn't to leak any memory, then you don't have any leaks to find. So instead of using raw pointers use a wrapped pointer of some sort, instead of dynamically allocated arrays use std::vector. The moral is if you don't manually manage it you can't leak it. Cheers, Ash
of course :)
-
What's the latest best approach to finding memory leaks in unmanaged C++ MFC code? I've read about LeakDiag but the latest version of that is a bit old (which leads me to guessing its not maintained anymore). I have a case where I get persistent memory growth after an operation. I do the operation which loads a bunch of data, then I free it all, and at the end my memory usage is up a bit from where it was before I loaded the data. I'm looking at Private Bytes and Working Set in Process Explorer and my app uses directly the Windows Heap APIs as well as CRT new/delete for allocating/freeing memory. I ran in the debugger (I'm using VS2005) and it didn't complain about any leaks as it sometimes does when you have leaks.
-
The best approach isn't to leak any memory, then you don't have any leaks to find. So instead of using raw pointers use a wrapped pointer of some sort, instead of dynamically allocated arrays use std::vector. The moral is if you don't manually manage it you can't leak it. Cheers, Ash
Aescleal wrote:
The moral is if you don't manually manage it you can't leak it.
Where's the fun, then (OK I didn't notice it was a 'moral'...). :)
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler. -- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong. -- Iain Clarke
[My articles] -
What's the latest best approach to finding memory leaks in unmanaged C++ MFC code? I've read about LeakDiag but the latest version of that is a bit old (which leads me to guessing its not maintained anymore). I have a case where I get persistent memory growth after an operation. I do the operation which loads a bunch of data, then I free it all, and at the end my memory usage is up a bit from where it was before I loaded the data. I'm looking at Private Bytes and Working Set in Process Explorer and my app uses directly the Windows Heap APIs as well as CRT new/delete for allocating/freeing memory. I ran in the debugger (I'm using VS2005) and it didn't complain about any leaks as it sometimes does when you have leaks.
The built-in detection mechanisms of the VS work very well for me ie., define new to DEBUG_NEW and so on. When you stop your application it will tell you where the leaks are if you do this. But, as others have said, the heap manager does not always release unused memory back to the OS. It tries to reuse the free blocks but sometimes memory gets fragmented and it has to allocate more to get a contiguous block of the needed size. You can 'manually' force it to release the memory back to the OS by calling _heapmin().
-
What's the latest best approach to finding memory leaks in unmanaged C++ MFC code? I've read about LeakDiag but the latest version of that is a bit old (which leads me to guessing its not maintained anymore). I have a case where I get persistent memory growth after an operation. I do the operation which loads a bunch of data, then I free it all, and at the end my memory usage is up a bit from where it was before I loaded the data. I'm looking at Private Bytes and Working Set in Process Explorer and my app uses directly the Windows Heap APIs as well as CRT new/delete for allocating/freeing memory. I ran in the debugger (I'm using VS2005) and it didn't complain about any leaks as it sometimes does when you have leaks.
We use Memory Validator here at work and it is fairly awesome. It will show where both the growth and leaks are occuring, assuming you generate proper PDB files for your project.
-
The built-in detection mechanisms of the VS work very well for me ie., define new to DEBUG_NEW and so on. When you stop your application it will tell you where the leaks are if you do this. But, as others have said, the heap manager does not always release unused memory back to the OS. It tries to reuse the free blocks but sometimes memory gets fragmented and it has to allocate more to get a contiguous block of the needed size. You can 'manually' force it to release the memory back to the OS by calling _heapmin().
I've successfully used the built-in VS leak stuff with DEBUG_NEW, etc in the past. For this, though, its not reporting any leaks. However, when I load a file, then do file>>new and dispose of everything, then repeat the process, I see a roughly constant growth each time. I'm looking at the process private bytes counter. I wrote a small test app which does HeapCreate/HeapAlloc/HeapFree/HeapDestroy and also new/delete. In either case, when I allocate a bunch of memory and then free it the private bytes immediately drops back down. Whereas in my app I get this persistent repeatable growth each time, yet the VS leak detection isn't kicking in. I'm not at all concerned about memory being released back to the OS. If the heap manager is holding onto it after my app has freed it (HeapFree/delete) that's acceptable and its an OS issue. I'm worried about cases where I've allocated and not freed the memory myself (regardless of whether or not its been returned to the OS).
-
We use Memory Validator here at work and it is fairly awesome. It will show where both the growth and leaks are occuring, assuming you generate proper PDB files for your project.
I'll take a look at that. Thanks!
-
Maybe I need to look at that again too. Thanks!