Comments on: Debugging memory leaks http://www.spamstopshere.com/blog/2008/03/28/debugging-memory-leaks/ IT and security blog Sun, 14 Mar 2010 14:39:36 +0000 http://wordpress.org/?v=2.3.3 By: victor louis http://www.spamstopshere.com/blog/2008/03/28/debugging-memory-leaks/#comment-109 victor louis Wed, 23 Apr 2008 04:59:31 +0000 http://www.spamstopshere.com/blog/2008/03/28/debugging-memory-leaks/#comment-109 You can prevent memory leaks by watching for some common problems. Collection classes, such as hash tables and vectors, are common places to find the cause of a memory leak. This is particularly true if the class has been declared static and exists for the life of the application. . The prevalence of memory leak bugs has led to the development of a number of debugging tools to detect unreachable memory. Coverity Prevent is one of the tool that you can use for fixing these kinds of bugs. Coverity Prevent is also used by the Department of Homeland security to scan many open source projects. You can get more info at http://www.Coverity.com You can prevent memory leaks by watching for some common problems. Collection classes, such as hash tables and vectors, are common places to find the cause of a memory leak. This is particularly true if the class has been declared static and exists for the life of the application. . The prevalence of memory leak bugs has led to the development of a number of debugging tools to detect unreachable memory. Coverity Prevent is one of the tool that you can use for fixing these kinds of bugs. Coverity Prevent is also used by the Department of Homeland security to scan many open source projects. You can get more info at http://www.Coverity.com

]]> By: Marcus http://www.spamstopshere.com/blog/2008/03/28/debugging-memory-leaks/#comment-5 Marcus Wed, 02 Apr 2008 20:48:38 +0000 http://www.spamstopshere.com/blog/2008/03/28/debugging-memory-leaks/#comment-5 I'd like to point out that processes often use more memory than is reported by a tool such as Top or Task Manager. Those tools typically report only the real (or system) memory for each process. You should always look at the amount of virtual memory that a process is holding for a true report of the amount of memory that a process is using. A process may be using 1 GB of memory, even though you might only have .5 GB of RAM. Top or Task Manager may show that the process is using .25 GB because that is how much real (system) memory that the OS is letting the process have. However, the process may in fact be swapping out memory frequently with the virtual memory. If you look at the virtual memory usage, you'll see the true 1 GB of memory being used. Use the "ps -aux" command to view the virtual memory of processes. The VSZ column shows the virtual memory, and the RSS column shows the real memory. For Windows, add the "Virtual Memory Size" column to Task Manager's Processes tab. Mem Usage is the real memory. VM Size is the virtual memory. I'd also like to explain what a memory leak is for those who don't know. First a little background. At runtime, a process frequently requests memory from the operating system's memory manager. The process uses the memory to temporarily store data. When the data is no longer needed, the process must "free" the memory to return it back to the operating system's memory manager. Now the definition. If the process fails to return the memory to the operating system before the register that holds the memory falls out of scope, the process effectively loses track of the memory, and the memory is unable to be returned to the operating system. This is called a memory leak. If this occurs repeatedly, a process will consume more and more memory from the operating system, and you'll see the virtual memory usage grow and grow. The memory can be returned to the operating system by ending the process. A memory leak is usually caused by a logic error, or bug, in a program, which should be fixed. It's interesting to note that Java and JavaScript automatically free memory through a process called automatic "garbage collection", so typically Java and JavaScript are immune to memory leaks, but there is a performance penalty for automatic garbage collection. I’d like to point out that processes often use more memory than is reported by a tool such as Top or Task Manager. Those tools typically report only the real (or system) memory for each process. You should always look at the amount of virtual memory that a process is holding for a true report of the amount of memory that a process is using.

A process may be using 1 GB of memory, even though you might only have .5 GB of RAM. Top or Task Manager may show that the process is using .25 GB because that is how much real (system) memory that the OS is letting the process have. However, the process may in fact be swapping out memory frequently with the virtual memory. If you look at the virtual memory usage, you’ll see the true 1 GB of memory being used.

Use the “ps -aux” command to view the virtual memory of processes. The VSZ column shows the virtual memory, and the RSS column shows the real memory.

For Windows, add the “Virtual Memory Size” column to Task Manager’s Processes tab. Mem Usage is the real memory. VM Size is the virtual memory.

I’d also like to explain what a memory leak is for those who don’t know.

First a little background.

At runtime, a process frequently requests memory from the operating system’s memory manager. The process uses the memory to temporarily store data. When the data is no longer needed, the process must “free” the memory to return it back to the operating system’s memory manager.

Now the definition.

If the process fails to return the memory to the operating system before the register that holds the memory falls out of scope, the process effectively loses track of the memory, and the memory is unable to be returned to the operating system. This is called a memory leak.

If this occurs repeatedly, a process will consume more and more memory from the operating system, and you’ll see the virtual memory usage grow and grow. The memory can be returned to the operating system by ending the process.

A memory leak is usually caused by a logic error, or bug, in a program, which should be fixed.

It’s interesting to note that Java and JavaScript automatically free memory through a process called automatic “garbage collection”, so typically Java and JavaScript are immune to memory leaks, but there is a performance penalty for automatic garbage collection.

]]>