Resource Leak
in [MFC]
|
From: Woody on 30 May 2010 04:24 On May 29, 9:19 am, "David Ching" <d...(a)remove-this.dcsoft.com> wrote: > Then what utility will tell you how much memory is committed to your app at > any given time? Try VMMap, from www.sysinternals.com. It shows details of your process's memory usage..
From: David Ching on 30 May 2010 13:25 "Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message news:hdq306192mp1p5jbh2b3kva60m1vubo103(a)4ax.com... > How much memory is committed, and how much is in use, are completely > different concepts. > And the amount committed is rarely interesting. > > The easy check for memory leaks is if Task Manager shows monotonically > increasing memory > usage. However, the notion that once you load a program or use a feature, > that the memory > will be "reclaimed" is usually ill-founded, and never has had any > existence in reality. OK, watching for steadily increasing memory consumption may indicate a problem, but not necessarily. Not good enough. SysInternals Process Explorer has some columns you can monitor such as Private Bytes, Minimum Working Set, and WS Private Bytes, and WS Shared Bytes. Maybe one of those would help. > Another example of the total uselessness of Task Manager deals with the > age-old question > "Why does my program get smaller when I minimize it?" Task Manager does > not report honest > numbers in the first place, and the values it returns are essentially > meaningless because > they do not represent actual memory footprint, and when it comes to data, > none of these > programs can tell you how much space is available for allocation. If you > allocate 20MB of > storage, in 100K blocks, then free them all, your memory footprint will > NOT decrease at > all, but you will have 20MB of free space that can be reallocated for > other purposes. So > in many cases you see a "high water mark" rather than any real picture of > what is going > on. > Even if you minimize your app or programatically call SetProcessWorkingSetSize(), you are saying the size shown won't decrease? That's odd. > I tend to ignore Task Manager if I care about how memory is being used. I > will use > Process Explorer to understand code usage, and I will monitor the heap > myself if I care > about how the heap space is being used. How exactly do you "monitor the heap yourself"? I just can't believe there isn't a simple utility to tell you grossly whether or not your app is not huge portions of memory in a timely fashion. -- David
From: David Ching on 30 May 2010 14:20 "Woody" <ols6000(a)sbcglobal.net> wrote in message news:0f1f0424-cf8c-4363-b018-3ab58a22e3ff(a)q39g2000prh.googlegroups.com... > Try VMMap, from www.sysinternals.com. It shows details of your > process's memory usage.. Thanks, this looks very interesting! -- David
From: David Ching on 30 May 2010 18:49 "David Ching" <dc(a)remove-this.dcsoft.com> wrote in message news:5E5EA6F1-9723-4AF4-A32A-53068295AEC4(a)microsoft.com... > I just can't believe there isn't a simple utility to tell you grossly > whether or not your app is not huge portions of memory in a timely > fashion. > OK, I wrote a simple MFC dialog based app (ha, it's been awhile since I've done that, too much time in .NET-land, and it's like riding a bike, you just don't forget how!) that simply allocates a 1 MB block each time button A is clicked, and deallocates one of the allocated blocks (in LIFO order), each time button B is clicked. Knock on wood, trusty Process Explorer updates these metrics by 1 MB, like clockwork, each time either button is clicked: Process Explorer Metrics ---------------------------- Virtual Memory * Private Bytes * Virtual Size Physical Memory * Working Set * WS Private The Windows 7 Task Manager also reliably both increments and decrements the following metric as 1 MB blocks are allocated and deallocated: Windows 7 Task Manager ------------------------------ * Memory - Commit Size So, it would appear Task Manager and even more so, Process Explorer, are great tools for tracking memory leaks! -- David
From: Joseph M. Newcomer on 30 May 2010 21:36 See below... On Sun, 30 May 2010 10:25:56 -0700, "David Ching" <dc(a)remove-this.dcsoft.com> wrote: >"Joseph M. Newcomer" <newcomer(a)flounder.com> wrote in message >news:hdq306192mp1p5jbh2b3kva60m1vubo103(a)4ax.com... >> How much memory is committed, and how much is in use, are completely >> different concepts. >> And the amount committed is rarely interesting. >> >> The easy check for memory leaks is if Task Manager shows monotonically >> increasing memory >> usage. However, the notion that once you load a program or use a feature, >> that the memory >> will be "reclaimed" is usually ill-founded, and never has had any >> existence in reality. > >OK, watching for steadily increasing memory consumption may indicate a >problem, but not necessarily. Not good enough. SysInternals Process >Explorer has some columns you can monitor such as Private Bytes, Minimum >Working Set, and WS Private Bytes, and WS Shared Bytes. Maybe one of those >would help. **** I agree. it is only *suggestive* of a leak. And only if it monotonically increases at a rate that is reasonably steady and which correlates with behavior that is not expected to cause leaks; that is, you do X, and each time you do X, memory gets bigger, and you do not expect X to make memory grow unreasonably, then there is a leak in doing X. But as you say, it is not definitive The Sysinternals tool only gives values which are vaguely indicative of what the program is doing. Like task manager, these numbers have very little use for analyzing the details of WHY memory is growing. **** > > >> Another example of the total uselessness of Task Manager deals with the >> age-old question >> "Why does my program get smaller when I minimize it?" Task Manager does >> not report honest >> numbers in the first place, and the values it returns are essentially >> meaningless because >> they do not represent actual memory footprint, and when it comes to data, >> none of these >> programs can tell you how much space is available for allocation. If you >> allocate 20MB of >> storage, in 100K blocks, then free them all, your memory footprint will >> NOT decrease at >> all, but you will have 20MB of free space that can be reallocated for >> other purposes. So >> in many cases you see a "high water mark" rather than any real picture of >> what is going >> on. >> > >Even if you minimize your app or programatically call >SetProcessWorkingSetSize(), you are saying the size shown won't decrease? >That's odd. **** Actually, Task Manager does show that after programmatically reducing the working set, the size goes down; this is the basis of what Mark Russinovich termed "fraudware", that is, those $29.95 programs that purportedly make the computer run "faster" by reducing all the program sizes to 0. But this is not useful for predicting what is going to happen, because if your memory footprint keeps growing, you are only going to get more and more page faults as you make the program "smaller". So the Task Manager information is not actually useful, yet again. **** > > >> I tend to ignore Task Manager if I care about how memory is being used. I >> will use >> Process Explorer to understand code usage, and I will monitor the heap >> myself if I care >> about how the heap space is being used. > >How exactly do you "monitor the heap yourself"? **** _heapwalk. Tedious, huge number of potential page faults, but absolutely honest numbers of what your instantaneous storage consumption is. Not an elegant solution, but one which actually works (unlike most of the alternatives I've head proposed). **** > >I just can't believe there isn't a simple utility to tell you grossly >whether or not your app is not huge portions of memory in a timely fashion. **** I have not found one. I gave up trying ten years ago, when we really needed to get the data for an app we were having trouble with (I didn't write the app, and it was huge, over 100K SLOC, and I didn't have time to read every single line looking for the storage leak. > >-- David Joseph M. Newcomer [MVP] email: newcomer(a)flounder.com Web: http://www.flounder.com MVP Tips: http://www.flounder.com/mvp_tips.htm
First
|
Prev
|
Next
|
Last
Pages: 1 2 3 4 Prev: VC++2010 EXPRESS Next: Manifest Hell - a thing of the past? |