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 requested). 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.
Detecting a Better Tool
So let's make a wish list of requirements for a memory-leaks detection tool (I'm only talking about management of runtime info regarding memory use, and not about techniques to trap allocations/deallocations made by the program):
- They should let you begin registering new memory allocations at any arbitrary point of time. You will let the application properly initialize first.
- They should stop monitoring memory activities and get a current-leaks report at any time.
Returning to the web server example, assume that it holds a session context per user—this is some information needed to process all requests made by the same visitor. As you don't want to keep this information forever, you release all related objects after a timeout of 20 minutes from the visitor's last request. Figure 1 shows a schematic lifetime of session objects, assuming that you start monitoring at time 1 and end at time 7.
At time 7 (when you end memory monitoring), session objects for Ron and Superman are still alive, and they were allocated during the monitoring interval. As a result, those session objects would be listed as memory leaks, even if you know that they aren't. That is exactly what you tried to prevent.
As a solution, you need to rethink the second requirement and replace it with:
- You should be able to stop registering new memory allocations, while still updating the state on each released object.
- At time (c), you want to get a report of all memory blocks allocated in time period (a)-(b), which were not released within the (a)-(c) time interval.
For the imaginary web server, assume you've started the process at 10:00. You can begin all monitoring at 10:10; turn off new allocations tracing at 10:15; and only at 10:40 get the final report of all memory leaks (for objects allocated in the five minutes between 10:10 and 10:15). Such flexibility in activation times and separation of new and delete processing are key points in building a better memory-leaks detection tool.
When thinking about additional features it might have, I would add:
- Start monitoring only memory allocation made from a specific thread or group of threads.
Again, this is a good way to focus on specific areas of processing, ignoring unnecessary noise in reports. For example, a web server may have a pool of threads that handles user requests. You suspect that the memory leak is hiding in the code processing those requests, so you want to filter out all allocations made from other parts of the code. In many cases, you still want to process all memory deallocations, even in other threads (for example, you may send objects from processor threads to a special logger thread, and have the latter release those objects).
