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.
-
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.
Sorry i can't answer your actual question, since i don't know what cool memory leak detection ways there are but i not so long ago we ran into some memory-fragmentation problems with our projects and we had to dig a bit deeper into memory management to cope with it and we leartn a few new things. You might be experiencing slight memory usage increase because -as far as i know- CRT doesn't always "physically" free up memory when you call delete/free, it preserves some amount so it can quickly reuse it when new allocations are needed, i think it mostly does that for smaller allocations because it is more efficient that way, am not sure how you could test if this is the case or not though...
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
-
Sorry i can't answer your actual question, since i don't know what cool memory leak detection ways there are but i not so long ago we ran into some memory-fragmentation problems with our projects and we had to dig a bit deeper into memory management to cope with it and we leartn a few new things. You might be experiencing slight memory usage increase because -as far as i know- CRT doesn't always "physically" free up memory when you call delete/free, it preserves some amount so it can quickly reuse it when new allocations are needed, i think it mostly does that for smaller allocations because it is more efficient that way, am not sure how you could test if this is the case or not though...
> The problem with computers is that they do what you tell them to do and not what you want them to do. < > "It doesn't work, fix it" does not qualify as a bug report. < > Amazing what new features none of the programmers working on the project ever heard of you can learn about when reading what the marketing guys wrote about it. <
I thought that too, but I wrote a small test app which did a bunch of new ops then, when requested, freed them all. What I noticed was that (when viewing these columns in Process Explorer) the virtual size never dropped back down. It just stayed where it was after all the new calls. But, the private bytes and working set did drop right back down after freeing the memory. And its these 2 columns where I'm seeing the persistent growth. I check the memory usage, then load the data, the free it all, then check again and repeat this multiple times with the same instance of the app. Each time I get a growth in those columns.
-
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.
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.)
-
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!