Memory issues are amongst the worst one to solve because pointing precisely the source is often difficult and painful. Memory leaks are not an exception, especially with real-world application: most of the time, programmers start to worry about it when the application outputs some “out of memory” errors. At this moment, you have to find which one, among thousands of functions and many more allocated blocks, causes the application to leak and eventually to crash.
Let’s summarize what you really need when you have a memory leak (in addition to a way to reproduce the issue):
- You want to find which object(s) are leaking
- You want to know why they are leaking: is there some static reference to it, or maybe they are not freed?
The process described today deals with the first one, which is often the most difficult.
To cope with the various needs of any kind of software, every operating system offer a generalist memory management system. As it works out-of-the-box most of the time, developers usually don’t dig into it to find how it behaves under the hood. But you may be surprised to know that you can not access all the memory of your process, even when some parts seem to be free. Beyond available memory and fragmentation of user space, there is another barrier that can prevent you to get the remaining free bits : the heap service and the minimum size of a virtual allocation call.
Imagine a software who, after a few hours of uptime, starts to throw out-of-memory exceptions. First thought is that, indeed, you don’t have enough memory left. Let’s say that 1Go is free, and that you just ask for a small block of 30k. If you’re familiar with memory issues, second thought may be: “memory fragmentation! Check the largest contiguous block!”. And if I say that a block of 60k is available ? Well, if you are like me before this issue happens at my work, you’re stuck. But let’s go back to the beginning.