Memory Testing in Software Development

Modern software development practices are designed to nurture the fastest possible throughput for changes to an application. Indeed, Agile development practices, which most development efforts are now guided by, is designed around throughput efficiency. Sacrifices are often made in order to deliver code on time; it is often the deep testing of application code which is sacrificed first. Memory and performance problems are among the most difficult to solve and often go undetected – especially where the root cause is related to the size or addressing of a variable and is therefore intermittent or conditional.

Really big data sets exacerbate the problem of effectively testing application changes. RAM which is used inefficiently may become unaddressable or fragmented. Multi-threaded or multi-processed application can create unique memory issues for developers when by-reference addressing of variables is used.

Developers of C, C++ and Fortran, plus those developers using Python to make use of unmanaged libraries, have a powerful tool they can use easily to look for, and remediate, even the most elusive memory-related coding issues.

What Is Memory Leak?

A memory leak in an unmanaged application refers to memory, or pointers to memory addresses, becoming unreachable or unusable once released (orphaned), but it more commonly is used to talk about many types of memory-centric problems.

In practical terms, if computer memory is “dirty”, blocked, populated by unknown or unexpected values, is unreachable or unchanging, developers will approach the task of triage in much the same way; triage of memory related problems is notoriously problematic and requires powerful tools with in depth knowledge of how memory management works.

What Causes Memory Leaks?

The short answer to what causes memory leaks is “we do”; developers write the code which becomes an application with vulnerabilities in it. The common vulnerabilities and exposures (CVE) list details vulnerabilities like memory leaks.

This is why having the right tools are a developer’s greatest weapon in the fight for code perfection.

There are many reasons memory may be lost to the application. I may create a block of addressable memory, but later loose track of it:

	
void *pointer = malloc (12345); // allocate memory and store pointer address
pointer = malloc (534345); //allocated again
free pointer;  //only frees the second assignment

In the lines above, I have lost the ability to use the first allocation, and that memory is now lost to the application and may require a restart of the host to reclaim the lost memory.

I may also over-write my allocated memory space in unmanaged languages. I may write a string value, the length of which is larger than the space allocated; while technically a memory overrun, this kind of problem is very difficult to triage and uses the same discipline to resolve as does the memory leak.

There are also potential issues with pointers, mismatches in allocation/deallocation of memory, issues with uninitialized memory, and issues across multiple program instruction stacks or program threads to consider.

Memory management of unmanaged applications ranks among the most difficult of development debugging tasks. It requires knowledge and tooling to efficiently triage software. 

Memory Debugging Technology

The TotalView memory debugging solution provides C and C++ leak detection, memory write overrun detection, and a variety of other memory validation checks. Developers typically use the TotalView user interface to find memory problems in their program, but may not know about a script-driven interface for use in automated environments, such as CI deployments.

Our underlying memory-tracking technology does not require any recompilation or special build of the target application. Instead, it dynamically proxies between your program and the underlying system memory function calls to track all memory-related activity. This solution enables developers to check memory usage on target applications “on the fly,” with minimal runtime overhead.

TotalView script interface, memscript, enables applications to test for memory leaks run within an automated test environment. The script generates output logs and memory recording files, including leak detection results and notifications of any illegal uses of memory. If memory leaks or memory use errors are detected, developers can load the generated memory recording files into the TotalView user interface and analyze the program’s use of memory. The script-based memory debugging functionality provides the basis for integration into your CI system.

Learn more about Memory Leaks and Errors in Parallel Applications.

Read the White Paper

Further Reading

• Learn about using tools to secure and optimize processes at scale with Perforce's enterprise automation 101
• How to Test for Memory Leaks in Jenkins
• Memory Leak Testing in Continuous Integration Systems