0

I want to find memory leak (using windows 7 OS) for the C++ program by observing "windows task manager" processes tab for gradual increase in memory. I am confused as i see lot of column's related to memory that i listed below in "windows task manager's" process tab. Memory - Working Set Memory - Working Set Delta Memory - Private Working Set Memory - Commit Size Memory - Paged Pool Memory - Non-paged Pool

I have searched topic related to this on web, but i couldn't get satisfactory answer.

Please let me know which indicator i should use to check increase in memory so that i can decide if my C++ code\process is having memory leak.

FYI My limitation is; I cannot use any profiling tool or static code analyzer tool and only have windows task manager access on the system to find memory leak.

Jack
  • 193
  • 1
  • 14
  • 3
    Sorry to disappoint you but a gradually increasing memory usage does **not** indicate a memory leak. A program does not have to return memory to the O/S when it frees memory. Only when the program exits will all the memory be returned to the O/S. If your memory usage is gradually increasing it might indicate that you have to do something about your memory usage, but it does not by itself indicate a memory leak. – john Oct 23 '12 at 09:24
  • really bad way to find a leak... The only time I found a leak was because I was doing a video codec and i was not freeing frames... Which was around 2mb leak per second. – UmNyobe Oct 23 '12 at 09:25
  • If memory is continuously increasing after repeating same set of inputs\requests to the process then there is definitely memory leak. I am observing this by firing same set of request to the process and just want to inform support team to take action on the issue. – Jack Oct 23 '12 at 09:43
  • There are several issues that manifest themselves with increasing virtual memory use, heap fragmentation is a common one in C++ programs - lots of room in the heap but small fragments that are not contiguous. That's not a memory leak though. The Working Set is only the RAM it is using at the time, you could have a memory leak and never see the symptoms in Task Manager. – cdarke Oct 23 '12 at 09:44
  • 1
    I think the answer to the question you asked is to use "commit size". Assuming a persistent leak it will continue to rise even in the case where the leaked memory is paged out and never touched again. But that comes with so many caveats about inaccuracy that I'm not sure it deserves to be an answer... – Steve Jessop Oct 23 '12 at 09:50
  • If you develop a program and know exactly what it is doing, then Task Manager can help you to confirm that there is some leaking memory part. But without memory analysis there is certainly not enough proof for your team that there is an actual memory leak. – SChepurin Oct 23 '12 at 09:55
  • @Jack No that it not true, you have a problem sure, but it isn't necessarily a memory leak, which has a quite specific meaning. It could for instance be memory fragmentation. – john Oct 23 '12 at 10:00

3 Answers3

4

As other posters have said, a slowly increasing and small increase does not necessarily indicate a problem.

However, if you have a long running process that slowly eats up vastly more memory than theoretically should be required (or has been measured in a healthy version of your component under similar usage scenarios) then you likely have a memory leak. I have first noticed problems in components by others reporting gigabyte usage of memory by the component (which normally uses about 2-3MB). Perfmon is useful if you want to see a long term view of your process memory. You can select the process by name, and then select the private bytes measure, and set up the timing and the grid to measure over (say) 24hrs.

Once you are sure that there is a definite increase in process memory, you can use tools like your debugger, Valgrind, Parasoft, Glow Code etc... to make sure what you are seeing is a real memory leak. However even if it is not a real memory leak (unreferenced heap memory) then you still need to redesign your component if your memory usage is increasing without end.

Dennis
  • 3,683
  • 1
  • 21
  • 43
  • 2
    +1 for being the first to actually try to answer the OP's questions, instead of swaying him away from even trying. Also for being the first to admit, that although it's not a definite indication of a leak, an increase in mem usage in the task manager is indeed an indication that more attention is required – Neowizard Oct 23 '12 at 10:08
0

The short answer: It's not possible.

With only looking at task manager, there just ins't enough data available. A memory leak typically is memory that is still allocated, but isn't used anymore; to the task manager, however, it looks as if the process would still use that memory (and it has no way of finding out). You might note a continuous increase in memory usage, but that's only an indicator that there might be memory leaks - it could also be that the programm really uses that memory (or holds on to that memory for future use, e.g. because it uses its own memory management). Without using additional tools, you cannot know.

codeling
  • 11,056
  • 4
  • 42
  • 71
  • I just want to decide weather the particular process is leaking memory or not over the period of time, if it is leaking memory, then i want to go back and tell my back end team to take action. – Jack Oct 23 '12 at 09:36
  • 1
    As I said, it's not possible. Something unclear about my explanation as to why that is? – codeling Oct 23 '12 at 09:38
0

To confirm your suspicion about leaking part, you can take as an example Perfmon memory analysis -

Private Bytes are a reasonable approximation of the amount of memory your executable is using and can be used to help narrow down a list of potential candidates for a memory leak; if you see the number growing and growing constantly and endlessly, you would want to check that process for a leak. This cannot, however, prove that there is or is not a leak.

See for details - What is private bytes, virtual bytes, working set?

Community
  • 1
  • 1
SChepurin
  • 1,814
  • 25
  • 17