For better or worst, I prefer to write my own memory leak checker for most of the projects I worked on. After did it a few times, it normally take less than 1

For better or worst, I prefer to write my own memory leak checker for most of the projects I worked on. After did it a few times, it normally take less than 1 days to put in the code - basically wrapper for malloc, free, etc, new, delete. Add some table code to track bytes alloc/ free per filename/line#. It must have a very concise high level table dump memory alloc/free associate with file:lineno. file:lineno: #Alloc_ByteCnt #Free_ByteCnt Advantages: It works very well on app that need to runs forever. One can easily track memory usage/leakage over time, but adding a trigger to dump the memory table without killing the app. The trigger can be TestAPI call or external URL. If you have a full functional regression test coverage system in place (All my projects has them), one can easily trigger the memory table dump along with certain test points. Fairly easy to ID memory leak associate with very high level functionalities such as * certain image load trigger 200K leak per test loop. * Certain URL access trigger file:line leak 64 bytes per test loop * , etc Once all these setup in place, memory leak are fairly trivial to solved. I have not seen any user space memory leak that take more than 1 hours to solve and verify. The most complex memory leak I had to debug was the EGL app that trigger EGL kernel driver memory leak at ~20MB per over night testing. To debug that was much harder..... Because that was the kernel/system memory is leaking not just user APP memory.