Friday, March 23, 2012

Memory Profiling


Here we will see about memory profiling, i.e. debugging programs that consume too much memory. Excessive memory consumption can be due to either inefficient data structures, missing memory deallocation, or simply because of an incorrect estimate on how much memory the program will need. Excessive memory use can also increase the runtime of a program, by forcing the program to access main memory instead of the faster cache, and by overflowing the available main memory (paging).

Memory profilers

Memory profilers are tools that do detailed book keeping of memory usage. Because most of these tool only watch dynamic memory allocated on the heap with malloc()/new, they are also called heap profilers. A memory profiler keeps records when a piece of dynamic memory is allocated, by whom (call stack) it was allocated, its size and when and by whom it was deallocated. After the program ends, the memory profiler outputs graphs and log files which reveal details about the memory usage and make it easy to locate the largest memory users.

Some of the memory profilers are:

AQtime

AQtime is a commercial tool sold by AutomatedQA. It is a runtime and memory profiler that works on Windows with the Microsoft, Borland, Intel, Compaq, and GNU compilers. AQtime is integrated into Microsoft Visual Studio and Borland Developer Studio.

Detailed Information can be found at: http://www.automatedqa.com/products/aqtime

mpatrol

mpatrol is an Open Source software memory debugger which also has memory profiling abilities. It is a library that is linked into the executable and intercepts calls to malloc(), free(), and similar functions. The use model is similar to gprof. 

Detailed Information can be found at: http://sourceforge.net/projects/mpatrol

Massif

Massif is a heap profiler. It measures how much heap memory your program uses. This includes both the useful space, and the extra bytes allocated for book-keeping and alignment purposes. It can also measure the size of your program's stack(s), although it does not do so by default. 
It is part of valgrind tool.
Detailed information can be found at: http://valgrind.org/

Memory Management Issues


The C/C++ language is able to manage memory resources, and can access memory directly through pointers.The allocation of dynamic memory (also known as heap memory) in C/C++ is under the control of the programmer. New memory is allocated with functions such as malloc() and various forms of the operator new. Unused memory is returned with free() or delete.

The memory handling in C/C++ gives a large degree of freedom, control, and performance, but comes at a high price: the memory access is a frequent source of bugs. The most frequent sources of memory access bugs are memory leaks, incorrect use of memory management, buffer overruns, and reading uninitialized memory.

Memory Leaks

Memory leaks are data structures that are allocated at runtime, but not deallocated once they are no longer needed in the program. If the leaks are frequent or large, eventually all available main memory in your computer will be consumed. The program will first slow down, as the computer starts swapping pages to virtual memory, and then fail with an out-of-memory error.

Incorrect Use of Memory Management

A whole class of bugs is associated with incorrect calls to memory management: freeing a block of memory more than once, accessing memory after freeing it, or freeing a block that was never allocated.

Buffer Overruns

Buffer overruns are bugs where memory outside of the allocated boundaries is overwritten, or corrupted. Buffer overruns can occur for global variables, local variables on the stack, and dynamic variables that were allocated on the heap with memory management.

One nasty artifact of memory corruption is that the bug may not become visible at the statement where the memory is overwritten. Only later, another statement in the program will access this memory location. Because the memory location has an illegal value, the program can behave incorrectly in a number of ways: the program may compute a wrong result, or, if the illegal value is in a pointer, the program will try to access protected memory and crash. If a function pointer variable is overwritten, the program will do a jump and try to execute data as program code.

Uninitialized Memory Bugs

Reading uninitialized memory can occur because C/C++ allows creation of variables without an initial value.The memory allocation function malloc() and operator new also do not initialize or zero out the allocated memory blocks.

Wednesday, March 7, 2012

Memory Debuggers

Memory debuggers do detailed bookkeeping of all allocated/deallocated dynamic memory. They also intercept and check access to dynamic memory. Some memory debuggers can check access to local variables on the stack and statically allocated memory.

Purify
Purify is a commercial memory debugging tool, available on Linux, Windows, and Solaris. Purify works by instrumenting the object code of a program during the link phase. No source code is required, and no special compiler flags or a recompilation of the object files are needed.
More information is available here:

Valgrind
Valgrind is Open Source software. It currently is available on Linux for x86 and PowerPC processors. The use model of Valgrind is simple. Valgrind interprets the object code, so it does not need to modify object files or executable, and therefore does not require special compiler flags, recompiling, or relinking the program. The
valgrind command is simply added at the shell command line, in front of the program to be executed. A further advantage of Valgrind is that no program source code is required, so Valgrind can be used to analyze black-box software modules from third parties where the source code is confidential and unavailable.
Valgrind comes as a collection of tools for the following purposes:
• Memcheck: a memory checker
• Callgrind: a runtime profiler
• Cachegrind: a cache profiler
• Helgrind: find race conditions
• Massif: a memory profiler
Documentation and download instructions for Valgrind are available here:

Insure++
Insure++ is a commercial tool for detecting runtime memory errors. Insure++ uses source code instrumentation: it modifies the source on the fly just before it is given to the compiler. This use model requires recompilation of the source files. There is some provision to support object code libraries where source code is not available.
More information is available here: