Dr. Dobb's Journal - January 2008 - (Page 59) d01gopsh_p4ma 11/9/07 11:18 AM Page 59 by Michael Gopshtein State of the Art Memory Leaks Detection: A Different Approach There are different ways to manage dynamically allocated memory Experienced C/C++ programmers know about the need to properly manage dynamically allocated memory to avoid memory leaks. Unfortunately, many of us still find ourselves in a tough position when there is a memory leak in the software. How is it detected in the first place? Simply looking at the task manager (or other appropriate tool that shows memory-use statistics) indicates that the memory used by the process is constantly growing. That means that the memory use is expected to remain constant. But the program must allocate memory, at least at the beginning of its life. Therefore, a more precise description would be that the process is running for a while, the input rate is constant, and the memory continues to climb. The interpretation of the input rate depends on the purpose of the program; for a web server, for instance, it can be network traffic throughput, or the number of requests per second. How do you attack this problem? Assume that your first attempts at just looking at the code failed, and you need to get help from an automatic memory-leak detection tool. While your favorite tool may use unique techniques to trace memory allocation/deallocation and different algorithms to organize that information at runtime, it most probably works like this: 1. From the moment the program starts, it traces each memory allocation (probably with additional information, such as a call stack). 2. It registers all released memory. 3. Before the program terminates, it prints out information about each unreleased memory block. ed). Other examples include custom memory pools, which can allocate up to a certain maximum number of objects, then reuse them through the rest of the process’s life. In all these cases, the memory is never released. Although it’s a good practice to clean up all resources, it doesn’t always happen. I can even give you a reason for releasing those objects—it slows the shutdown process of your program. But what’s more important is that all the memory used by the process is automatically reclaimed by the operating system (on most modern systems), and while the process is running, the size of all that static memory is known in advance and is strictly limited. The second reason is that memory leaks, which would be missed by such reports, can be defined as “Java-style memory leaks.” That is, although the object is no longer needed (at least according to the program’s logic), it is never deleted because you have a valid pointer to that object, probably lost in some cache or other container. And if this object is properly wrapped with a smart pointer, it will be deleted at the end and won’t appear as a memory leak. Needless to say, this is a common reason for constantly growing memory. Any remaining classical memory leaks, which can be detected in the usual way, may still be missed because they’re hard to discover in the background of other false alarms. January 2008 l www.ddj.com l Dr. Dobb’s Journal Michael is a software engineer for HP IT Management Software and can be contacted at mgopshtein@gmail.com. When Good Isn’t Good Enough In many cases, there are two reasons why memory-leak reports won’t give you much useful information. First, they complain about many nonexisting memory leaks and miss many real ones. Say, for instance, that there are many memory allocations that are never released by design. Those are the static members, allocated at the beginning of the process, and Singleton objects created later using a lazy initialization strategy (for instance, your web server may load a static file to the memory when it is first request- 59 http://www.ddj.com
For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.