Debugopedia

Some of the key issues and causes of memory leaks

Re-use of code

Tracking a leaked block in heap memory

It seems that code re-use is one of the most common means by which lurking memory leak problems are surfaced. Whenever an attempt is made to conveniently avoid re-inventing the wheel by recycling older codes, there is a likelihood that a new user may not spend adequate time to fully review all of the memory-related behavior of the program being used. Someone reusing code may often make assumptions about where and how memory is being used and deallocated.

Also, the use of Non-Uniform Memory Access (NUMA) architectures or shared memory environments can often hide or at least obscure such information. Sometimes it can be a matter of developers using different methods of reference counting (a technique of storing the number of references and pointers in memory) that can generate a mismatch in the deallocation process and introduce memory leaks.

Finally, re-factored code is often copied and pasted.  Sometimes you can get away with that without paying too much attention. But if it’s not done correctly, the error can be quite tough to spot if you don’t know exactly what you’re looking for.

Many codes are primarily Unit Tested with short runs and on small datasets

So why do many memory leaks go undetected, despite the best efforts of Testing and QA groups?  Most often, testing procedures are understandably heavily focused on key issues such as accuracy, compatibility, and performance. These procedures generally consist of many short tests run quickly on small data sets, followed by a data verification process.  Even  so-called “stress tests” often consist of cycling through multiple relatively short runs. Most memory leaks simply don’t surface as fatal or critical issues in these circumstances.

Users may use software (or library routines) in unexpected ways

The real impact of undetected memory leaks generally comes along later, and usually in unpredictable ways.  For instance, when you run a program longer than anticipated, memory leaks eventually cause an out-of-memory condition.  Also, it is not uncommon for programs sometimes to be used in unexpected ways that ultimately exacerbate the amount of memory leaked, creating problems seemingly out of the blue.  The point here is that you can’t always expect that a program will be used as anticipated (and tested for) initially.

Parasoft's Insure++ Memory Usage display screenshot

Leaks can linger in a code base and are often not immediately fatal

In many cases, leaving allocated memory lying around can be deemed relatively harmless, especially if there is a lot of memory available.  As long as there is adequate memory and the program terminates in a reasonably short time, there is some justification for that assessment. In some cases, memory leaks may never be detected. Given that many programs with memory leaks appear to run through basic testing without problems, it is not surprising that such software is often released into the wild with a clean bill of health.

[Prev: Memory leaks] [Next: More Causes ]