In unmanaged C/C++ code, what are the best practices to detect memory leaks? And coding guidelines to avoid? (As if it's that simple ;)
We have used a bit of a silly way in the past: having a counter increment for every memory allocation call and decrement while freeing. At the end of the program, the counter value should be zero.
I know this is not a great way and there are a few catches. (For instance, if you are freeing memory which was allocated by a platform API call, your allocation count will not exactly match your freeing count. Of course, then we incremented the counter when calling API calls that allocated memory.)
I am expecting your experiences, suggestions and maybe some references to tools which simplify this.
In terms of avoiding leaks the following post has some advice: http://stackoverflow.com/questions/27492/c-memory-management
I asked this question here: http://stackoverflow.com/questions/25730/what-is-the-best-free-memory-leak-detector-for-a-cc-program-and-its-plug-in-dlls and had great success with Visual Leak Detector.
I used this one with visual studio to detect mem leak. codeproject.com/KB/applications/visualleakdetector.aspx
you searh valgrin (for linux) or deleaker (for windows), also look visual leak detector...
for finding memory leaks check here:theunixshell.blogspot.com/2013/11/…
Valgrind also now works on OS X, so linux is not your only option.
Valgrind for Linux (and OS X). If you use windose - deleaker - best of all!
A note about this method: it appears that this only works if you are using pure C with malloc and free. The detailed report which includes line numbers is not created if you are using c++'s new and delete.
Zach: actually you can get this to work too (for any code you actually compile yourself, anyway) - see accepted answer in social.msdn.microsoft.com/forums/en-US/vcgeneral/thread/…
Will this work in release mode too ?
user3152463 No. According to the documentation, it will only work for the debug build: msdn.microsoft.com/en-us/library/e5ewb1h3(v=vs.71).aspx
This line is wrong: #define CRTDBG_MAP_ALLOC It should be: #define _CRTDBG_MAP_ALLOC
and std:vector is a great replacement for when arrays (buffers) are deallocated in the same function they are allocated.
At least std::auto_ptr and boost::shared_ptr are still susceptible to leaks.
Only if you use them incorrectly, though I should admit that for std::auto_ptr using it incorrectly is quite easy.
Whilst this is good advice for coding standards, it does not answer the question. Even using shared_ptr can lead to leaks with circular dependences. And you can have "leaks" with unlimited caching strategies, which apply even to garbage-collected languages.
CashCow: you are correct. While I haven't seen it yet in practice, that's probably because I'm using them sparingly. To quote the answer below, "Use pointers only when absolutely necessary".
Visual Leak Detectore moved to new site vld.codeplex.com
VLD is a REALLY nice leak detector - I totally recommend it for everyone using VC++
+1 for point #1. This is absolutely the fundamental thing. Unfortunately, it looks to me like some of the biggest "C++" libraries tend to eschew stack allocation and/or RAII in favour of Pointers Everywhere, often for no discernible reason. So, they end up being 'C with Classes', not actual C++.
Link no longer works, try here for documentation: support.microsoft.com/kb/2580960 and here to download: microsoft.com/en-us/download/details.aspx?id=26798
This tool is really perfect! It saves you the trouble to use the _CrtDumpMemoryLeaks(); and friends, as described in MSDN. Just one include and it exposes everything! Even works in old C libraries!
The new version (for VS2013) is here: vld.codeplex.com
and do not forget rule of 3 or of 5 then
I checked out leakfinder and it looks okay, but just FYI it won't work as-is for x64 because it contains inline assembly.
move to: github.com/gperftools/gperftools
Memory Validator also provides filename and line number for C# that calls your native code. x64 version is in beta
splint is a newer replacement for lint.
user14788: Gimpel's PC-Lint product is much more modern than the old Unix lint. It has many checks specific to C++, which afaik splint does not. See the link in the answer (which I renamed from Lint to PC-Lint).
I don't see why slowdown makes the results useless. Surely memory that is leaked is leaked regardless of the speed at which the program runs. The point of these tools is to find leaks, so where's the problem? Did it run so slowly that you couldn't physically get it to cover all code paths in order to profile them?
mtrace isn't super helpful for C++