Memory leaks can be a pain to solve. Software developers spend countless hours debugging their programs to find out which code is causing a memory leak. On Linux systems, there are tools such as Valgrind which can help find the source of a memory leak in a program.
But, sometimes, a program seems to continuously leak memory, even though the programmer has exhausted all debugging techniques, and there seems to be no culprit in the code itself.
One other place to look that is not often mentioned while discussing memory leaks is the operating system itself. Yes, you read that right. The operating system might be the source of that ever-increasing memory load you’re dealing with. While many tutorials focus on the programmer’s code, they often fail to mention that an apparent memory leak can be caused by the operating system allocating memory to a program even when the program has not expressly requested it or does not currently need it.
In order to increase performance, operating systems try to anticipate future memory use from a program. In some cases, a program might request memory from the operating system, and then properly release it back to the operating system when it is no longer needed. But the operating system might keep that memory allocated to the program, anticipating that the program would keep requesting the memory.
The operating system might even allocate more memory to a program than it previously requested. This often happens when a program is creating a lot of objects. And even though the program is properly releasing the memory back to the operating system, the operating system might decide to keep the memory allocated instead of retaking it and having to go through the process of reallocating it to the program later.
One might argue that programs should not create a lot of objects then, in order to avoid causing the operating system to allocate memory that is not needed. But some programs do need to create a lot of objects for them to work properly. So, while both side might share a bit of responsibility in this case, the main point here is that a programmer needs to remember that not all “freed” memory is taken back by the operating system, and that the operating system might even allocate memory in advance.
Thankfully, for Linux systems, there is a way to tell the operating system to trim the heap memory allocated to a program. Once, you’ve made sure that you’ve freed the allocated memory back to the operating system, you can also tell the operating system that you don’t want it to keep the memory around allocated to your program (seemingly against your will). You do this by calling malloc_trim().
The man page for malloc_trim() says that:
“The malloc_trim() function attempts to release free memory at the top of the heap (by calling sbrk(2) with a suitable argument).
The pad argument specifies the amount of free space to leave untrimmed at the top of the heap. If this argument is 0, only the minimum amount of memory is maintained at the top of the heap (i.e., one page or less). A nonzero argument can be used to maintain some trailing space at the top of the heap in order to allow future allocations to be made without having to extend the heap with sbrk(2).”
So, if you are having an apparent memory leak, and can’t find the source, try calling malloc_trim() once in a while in your program.