Memory stability of a C++ application in Linux

Question

I want to verify the memory stability of a C++ application I wrote and compiled for Linux. It is a network application that responds to remote clients connectings in a rate of 10-20 connections per second. On long run, memory was rising to 50MB, eventhough the app was making calls to delete...

Investigation shows that Linux does not immediately free memory. So here are my questions :

How can force Linux to free memory I actually freed? At least I want to do this once to verify memory stability. Otherwise, is there any reliable memory indicator that can report memory my app is actually holding?

Answer 1

What you are seeing is most likely not a memory leak at all. Operating systems and malloc/new heaps both do very complex accounting of memory these days. This is, in general, a very good thing. Chances are any attempt on your part to force the OS to free the memory will only hurt both your application performance and overall system performance.

To illustrate:

1. The Heap reserves several areas of virtual memory for use. None of it is actually committed (backed by physical memory) until malloc'd.

2. You allocate memory. The Heap grows accordingly. You see this in task manager.

3. You allocate more memory on the Heap. It grows more.

4. You free memory allocated in Step 2. The Heap cannot shrink, however, because the memory in #3 is still allocated, and Heaps are unable to compact memory (it would invalidate your pointers).

5. You malloc/new more stuff. This may get tacked on after memory allocated in step #3, because it cannot fit in the area left open by free'ing #2, or because it would be inefficient for the Heap manager to scour the heap for the block left open by #2. (depends on the Heap implementation and the chunk size of memory being allocated/free'd)

So is that memory at step #2 now dead to the world? Not necessarily. For one thing, it will probably get reused eventually, once it becomes efficient to do so. In cases where it isn't reused, the Operating System itself may be able to use the CPU's Virtual Memory features (the TLB) to "remap" the unused memory right out from under your application, and assign it to another application -- on the fly. The Heap is aware of this and usually manages things in a way to help improve the OS's ability to remap pages.

These are valuable memory management techniques that have the unmitigated side effect of rendering fine-grained memory-leak detection via Process Explorer mostly useless. If you want to detect small memory leaks in the heap, then you'll need to use runtime heap leak-detection tools. Since you mentioned that you're able to build on Windows as well, I will note that Microsoft's CRT has adequate leak-checking tools built-in. Instructions for use found here:

http://msdn.microsoft.com/en-us/library/974tc9t1(v=vs.100).aspx

There are also open-source replacements for malloc available for use with GCC/Clang toolchains, though I have no direct experience with them. I think on Linux Valgrind is the preferred and more reliable method for leak-detection anyway. (and in my experience easier to use than MSVCRT Debug).