I want to detect memory leaks of my C++ program in Windows.
I read the documentation also on MSDN about mermoy leak detection and I also started using Visual Leak Detector.
I have a doubt about the reporting of the leaks.
I am expecting a file name with a line number, but I am always reported the text below.
It has all the component of a leak description ( block type, memory address, data, etc..)
except for the file name and the line number.
If it is a real leak?
If yes do you know why the file/line are not reported?
In the meantime I am having a look also at this url
Thanks
Detected memory leaks!
Dumping objects ->
{4723} normal block at 0x04AFB5B8, 8 bytes long.
Data: 2C 3F 00 00 28 3F 00 00
{1476} normal block at 0x04AC3B58, 12 bytes long.
Data: 00 CD CD CD EB 01 75 4C CA 3D 0B 00
Object dump complete.
I investigated quite some different ways of tracking memory leaks. They all have their advantages but also their disadvantages.
To understand their advantages and disadvantages, we have to understand the different mechanisms and requirements:
How are new, delete, malloc and free intercepted? Some tools use #define to redefine new, delete, malloc and free, but this relies on the correct order of the include files, and may give problems if a class contains e.g. a method called free (as is the case in Qt). The preprocessor will also redefine this method, which may lead to compilation errors or unresolved externals.
Another way is to overrule the global new and delete operators. This is a much cleaner solution, but fails is you have a 3rd party library that puts a new in the library, but the delete in the header (or vice versa).
How is the source of the call determined. If new,delete,... are intercepted using #define's, often the preprocessor symbols __FILE__ and __LINE__ are uses to get the source of the leak. However, if you have 'generic' functions in your code like e.g. CreateString(), then most of the leaks will be reported in these generic functions, which does not really help you.
An alternative is to get the call stack at run time. It can be quite easily done using the Windows StackWalk function, but in my experience, this is very very slow. A much faster alternative is to get the base-pointer directly, and to rely on the stack-frame-pointers (you must compile with /Oy- to get the stack-frame-pointers). You can get the frame (base) pointer like this: _asm mov DWORD PTR [FramePtr], ebp. Then simply loop and in the loop get the instruction pointer from ((ADDR *)FramePtr)[1]; and the next frame-pointer fromFramePtr = ((ADDR *)FramePtr)[0];
How to report the leaks at the exact moment. In my case, I want the leaks to be reported at the end of the application, but to be able to do this, you need a leak-reporting mechanism at the end of your application. This means that if you want to report your leaks yourself, you need to rely on global variables being destructed at the end of your application (and report the leaks in ths destructor of the global variable). For server-type applications, you are probably more interested in getting the difference in memory usage between two points in time.
And now the different leak-systems:
C RunTime: reports leaks at the end, but has no decent way of reporting call stacks. Its method of intercepting calls to new,delete,... may cause problems in combinations with 3rd party libraries (like Qt, Boost, ...)
External Microsoft utilities (like GFlags, UMDH,, ...): they seem to be able to only log differences between two points in time. However, the call stack seems to be much better, although the GFlags utility may set flags in the OS that may cause a serious slowdown of your application.
Visual Leak Detector. Seems to correctly find all leaks, but in my case it doesn't work since I have a 3rd party DLL that simply aborts the process at its DllUnload (seems to be a Windows 7 specific problem).
My personal favorite (and people will not agree with me, I'm sure), is to write your own memory manager. Intercepting can be easily done using global new and delete operators (with the possible problems mentioned above), and you can get the call stack as described above. This alternative also relies on being able to have code that is executed at the very last moment in your application.
When choosing an alternative, I found the following aspects very imporant for my situation:
I want it to work seemlessly in my application, so that every developer is notified immediately if there is a leak. If you delay leak-checking to a later moment where you use external utilities like Purify, leak-finding will be much harder.
I want leaks to be reported at the end of the application, automatically.
I want as much as possible information from the leak (the data, the call stack, ...)
Hope this helps.
This is the output from Visual Studio's own debug CRT, not the output from Visual Leak Detector. Firstly ensure that you're using the current version at Codeplex and that you have #included vld.h in your project. You will get a much more informative output.
I got it after debugging a lot of header files.
Here is what has to be done to enable file/line number in the output
#define _CRTDBG_MAP_ALLOC
#define _CRTDBG_MAP_ALLOC_NEW
Did you compile with debugging information enabled and ensure that the pdb file is available by the leak detector? Without this information it wouldn't be able to provide line numbers.
You should use Valgrind, it's very powerfull and explains properly where are the leaks located in your program. Your program may need to be compiled with gcc, though...
Rational Purify is available as a for-money plugin for VC++, and is a very good leak (and other trouble) detector. I used to use it a lot on Solaris, and it was very easy to use and clear. I've also heard good things from other people about the version for use with Visual Studio, but I've never actually tried that.
FWIW, I suspect that Purify was the inspiration for Valgrind, which has already been mentioned.
If the allocation numbers (the ones in the curled braces) are always the same, this could help. Basically, it described how to make VC++ generate a breakpoint when the allocation with the specified number is attempted.
I have been unable to find much or any information on this. I have a project which is built using VS2005, thus using the mscvr80.dll. My project also loads a third party library, which then loads up mscvrt60.dll.
Now I have a strange bug in my program where the program crashes with a memory read violation (in debug it is at 0xcdcdcdcd, which from my searches describes an non-initialized memory location). The debugger indicates that the violation is within an unknown function in the third party library.
I have contacted the owners of this library and they do not know of any error, as described. Also, I have other projects, compiled in VS60, which use this third party library, and that do not have similar errors. Thus I am wondering, can there be issues with using multiple common runtime versions? I remember vaguely hearing about situations where one runtime (say in the .dll) could allocate memory, and then if the other version tries to free this memory, that can cause issues. However, I cannot remember where I read this, nor can I find much information on the subject.
Any input is much appreciated.
Freeing memory allocated by one version of the runtime in another version can certainly cause problems. There's no guarantee that the implementation details of the CRT heap remained the same between versions. If you can't find any other work arounds, you can try compiling your application against mscvrt60.dll.
If you are seeing 0xcdcdcdcd, then you may be mixing the debug run-time library and the release run-time library. They should work OK together, but you might try replicating the issue using only the release runtime.
Yesterday, I got bit by a rather annoying crash when using DLLs compiled with GCC under Cygwin. Basically, as soon as you run with a debugger, you may end up landing in a debugging trap caused by RtlFreeHeap() receiving an address to something it did not allocate.
This is a known bug with GCC 3.4 on Cygwin. The situation arises because the libstdc++ library includes a "clever" optimization for empty strings. I spare you the details (see the references throughout this post), but whenever you allocate memory in one DLL for an std::string object that "belongs" to another DLL, you end up giving one heap a chunk to free that came from another heap. Hence the SIGTRAP in RtlFreeHeap().
There are other problems reported when exceptions are thrown across DLL boundaries.
This makes GCC 3.4 on Windows an unacceptable solution as soon as your project is based on DLLs and the STL. I have a few options to move past this option, many of which are very time-consuming and/or annoying:
I can patch my libstdc++ or rebuild it with the --enable-fully-dynamic-string configuration option
I can use static libraries instead, which increases my link time
I cannot (yet) switch to another compiler either, because of some other tools I'm using. The comments I find from some GCC people is that "it's almost never reported, so it's probably not a problem", which annoys me even more.
Does anyone have some news about this? I can't find any clear announcement that this has been fixed (the bug is still marked as "assigned"), except one comment on the GNU Radio bug tracker.
Thanks!
The general problem you're running into is that C++ was never really meant as a component language. It was really designed to be used to create complete standalone applications. Things like shared libraries and other such mechanisms were created by vendors on their own. Think of this example: suppose you created a C++ component that returns a C++ object. How is the C++ component know that it will be used by a C++ caller? And if the caller is a C++ application, why not just use the library directly?
Of course, the above information doesn't really help you.
Instead, I would create the shared libraries/DLLs such that you follow a couple of rules:
Any object created by a component is also destroyed by the same component.
A component can be safely unloaded when all of its created objects are destroyed.
You may have to create additional APIs in your component to ensure these rules, but by following these rules, it will ensure that problems like the one described won't happen.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
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.
If your C/C++ code is portable to *nix, few things are better than Valgrind.
If you are using Visual Studio, Microsoft provides some useful functions for detecting and debugging memory leaks.
I would start with this article:
https://msdn.microsoft.com/en-us/library/x98tx3cf(v=vs.140).aspx
Here is the quick summary of those articles. First, include these headers:
#define _CRTDBG_MAP_ALLOC
#include <stdlib.h>
#include <crtdbg.h>
Then you need to call this when your program exits:
_CrtDumpMemoryLeaks();
Alternatively, if your program does not exit in the same place every time, you can call this at the start of your program:
_CrtSetDbgFlag ( _CRTDBG_ALLOC_MEM_DF | _CRTDBG_LEAK_CHECK_DF );
Now when the program exits all the allocations that were not free'd will be printed in the Output Window along with the file they were allocated in and the allocation occurrence.
This strategy works for most programs. However, it becomes difficult or impossible in certain cases. Using third party libraries that do some initialization on startup may cause other objects to appear in the memory dump and can make tracking down your leaks difficult. Also, if any of your classes have members with the same name as any of the memory allocation routines( such as malloc ), the CRT debug macros will cause problems.
There are other techniques explained in the MSDN link referenced above that could be used as well.
In C++: use RAII. Smart pointers like std::unique_ptr, std::shared_ptr, std::weak_ptr are your friends.
As a C++ Developer here's some simply guidelines:
Use pointers only when absolutely necessary
If you need a pointer, doublecheck if a SmartPointer is a possibility
Use the GRASP Creator pattern.
As for the detection of memory leaks personally I've always used Visual Leak Detector and find it to be very useful.
I've been using DevStudio for far too many years now and it always amazes me just how many programmers don't know about the memory analysis tools that are available in the debug run time libraries. Here's a few links to get started with:
Tracking Heap Allocation Requests - specifically the section on Unique Allocation Request Numbers
_CrtSetDbgFlag
_CrtSetBreakAlloc
Of course, if you're not using DevStudio then this won't be particularly helpful.
I’m amazed no one mentioned DebugDiag for Windows OS.
It works on release builds, and even at the customer site.
(You just need to keep your release version PDBs, and configure DebugDiag to use Microsoft public symbol server)
Visual Leak Detector is a very good tool, altough it does not supports the calls on VC9 runtimes (MSVCR90D.DLL for example).
Microsoft VC++ in debug mode shows memory leaks, although it doesn't show where your leaks are.
If you are using C++ you can always avoid using new explicitly: you have vector, string, auto_ptr (pre C++11; replaced by unique_ptr in C++11), unique_ptr (C++11) and shared_ptr (C++11) in your arsenal.
When new is unavoidable, try to hide it in a constructor (and hide delete in a destructor); the same works for 3rd party APIs.
There are various replacement "malloc" libraries out there that will allow you to call a function at the end and it will tell you about all the unfreed memory, and in many cases, who malloced (or new'ed) it in the first place.
If you're using MS VC++, I can highly recommend this free tool from the codeproject:
leakfinder by Jochen Kalmbach.
You simply add the class to your project, and call
InitAllocCheck(ACOutput_XML)
DeInitAllocCheck()
before and after the code you want to check for leaks.
Once you've build and run the code, Jochen provides a neat GUI tool where you can load the resulting .xmlleaks file, and navigate through the call stack where each leak was generated to hunt down the offending line of code.
Rational's (now owned by IBM) PurifyPlus illustrates leaks in a similar fashion, but I find the leakfinder tool actually easier to use, with the bonus of it not costing several thousand dollars!
Never used it myself, but my C friends tell me Purify.
If you're using Visual Studio it might be worth looking at Bounds Checker. It's not free, but it's been incredibly helpful in finding leaks in my code. It doesn't just do memory leaks either, but also GDI resource leaks, WinAPI usage errors, and other stuff. It'll even show you where the leaked memory was initialized, making it much easier to track down the leak.
I think that there is no easy answer to this question. How you might really approach this solution depends on your requirements. Do you need a cross platform solution? Are you using new/delete or malloc/free (or both)? Are you really looking for just "leaks" or do you want better protection, such as detecting buffer overruns (or underruns)?
If you are working on the windows side, the MS debug runtime libraries have some basic debug detection functionality, and as another has already pointed out, there are several wrappers that can be included in your source to help with leak detection. Finding a package that can work with both new/delete and malloc/free obviously gives you more flexibility.
I don't know enough about the unix side to provide help, although again, others have.
But beyond just leak detection, there is the notion of detecting memory corruption via buffer overruns (or underruns). This type of debug functionality is I think more difficult than plain leak detection. This type of system is also further complicated if you are working with C++ objects because polymorhpic classes can be deleted in varying ways causing trickiness in determining the true base pointer that is being deleted. I know of no good "free" system that does decent protection for overruns. we have written a system (cross platform) and found it to be pretty challenging.
I'd like to offer something I've used at times in the past: a rudimentary leak checker which is source level and fairly automatic.
I'm giving this away for three reasons:
You might find it useful.
Though it's a bit krufty, I don't let that embarass me.
Even though it's tied to some win32 hooks, that should be easy to alleviate.
There are things of which you must be careful when using it: don't do anything that needs to lean on new in the underlying code, beware of the warnings about cases it might miss at the top of leakcheck.cpp, realize that if you turn on (and fix any issues with) the code that does image dumps, you may generate a huge file.
The design is meant to allow you to turn the checker on and off without recompiling everything that includes its header. Include leakcheck.h where you want to track checking and rebuild once. Thereafter, compile leakcheck.cpp with or without LEAKCHECK #define'd and then relink to turn it on and off. Including unleakcheck.h will turn it off locally in a file. Two macros are provided: CLEARALLOCINFO() will avoid reporting the same file and line inappropriately when you traverse allocating code that didn't include leakcheck.h. ALLOCFENCE() just drops a line in the generated report without doing any allocation.
Again, please realize that I haven't used this in a while and you may have to work with it a bit. I'm dropping it in to illustrate the idea. If there turns out to be sufficient interest, I'd be willing to work up an example, updating the code in the process, and replace the contents of the following URL with something nicer that includes a decently syntax-colored listing.
You can find it here: http://www.cse.ucsd.edu/~tkammeye/leakcheck.html
For Linux:
Try Google Perftools
There are a lot of tools that do similar alloc/free counting, the pros of Goolge Perftools:
Quite fast (in comparison to valgrind: very fast)
Comes with nice graphical display of results
Has other useful capabilities: cpu-profiling, memory-usage profiling...
The best defense against leaks is a program structure which minimizes the use of malloc. This is not only good from a programming perspective, but also improves performance and maintainability. I'm not talking about using other things in place of malloc, but in terms of re-using objects and keeping very explicit tabs on all objects being passed around rather than allocating willy-nilly like one often gets used to in languages with garbage collectors like Java.
For example, a program I work on has a bunch of frame objects representing image data. Each frame object has sub-data, which the frame's destructor frees. The program keeps a list of all frames that are allocated, and when it needs a new one, checks a list of unused frame objects to see if it can re-use an existing one rather than allocate a new one. On shutdown, it just iterates through the list, freeing everything.
I would recommend using Memory Validator from software verify.
This tool proved itself to be of invaluable help to help me track down memory leaks and to improve the memory management of the applications i am working on.
A very complete and fast tool.
Are you counting the allocs and frees by interpolating your own syscall functions which record the calls and then pass the call to the real function?
This is the only way you can keep track of calls originating from code that you haven't written.
Have a look at the man page for ld.so. Or ld.so.1 on some systems.
Also do Google LD_PRELOAD and you'll find some interesting articles explaining the technique over on www.itworld.com.
At least for MS VC++, the C Runtime library has several functions that I've found helpful in the past. Check the MSDN help for the _Crt* functions.
Paul Nettle's mmgr is a long time favourite tool of mine. You include mmgr.h in your source files, define TEST_MEMORY, and it delivers a textfile full of memory problems that occurred during a run of your app.
General Coding Guideline:
Resources should be deallocated at the same "layer" (function/class/library) where they are allocated.
If this is not possible, try to use some automatic deallocation (boost shared pointer...)
Memory debugging tools are worth their weight in gold but over the years I've found that two simple ideas can be used to prevent most memory/resource leaks from being coded in the first place.
Write release code immediatly after writing the acquisition code for the resources you want to allocate. With this method its harder to "forget" and in some sense forces one to seriously think of the lifecycle of resources being used upfront instead of as an aside.
Use return as sparringly as possible. What is allocated should only be freed in one place if possible. The conditional path between acquisition of resource and release should be designed to be as simple and obvious as possible.
At the top of this list (when I read it) was valgrind. Valgrind is excellent if you are able to reproduce the leak on a test system. I've used it with great success.
What if you've just noticed that the production system is leaking right now and you have no idea how to reproduce it in test? Some evidence of what's wrong is captured in the state of that production system, and it might be enough to provide an insight on where the problem is so you can reproduce it.
That's where Monte Carlo sampling comes into the picture. Read Raymond Chen's blog article,
“The poor man's way of identifying memory leaks” and then check out my implementation (assumes Linux, tested only on x86 and x86-64)
http://github.com/tialaramex/leakdice/tree/master
Working on Motorola cell phones operating system, we hijacked memory allocation library to observe all memory allocations. It helped to find a lot of problems with memory allocations.
Since prevention is better then curing, I would recommend to use static analysis tool like Klockwork or PC-Lint
Valgrind is a nice option for Linux. Under MacOS X, you can enable the MallocDebug library which has several options for debugging memory allocation problems (see the malloc manpage, the "ENVIRONMENT" section has the relevant details). The OS X SDK also includes a tool called MallocDebug (usually installed in /Developer/Applications/Performance Tools/) that can help you to monitor usage and leaks.
Detect:
Debug CRT
Avoid:
Smart pointers, boehm GC
A nice malloc, calloc and reallloc replacement is rmdebug, it's pretty simple to use. It is much faster to then valgrind, so you can test your code extensively. Of course it has some downsides, once you found a leak you probably still need to use valgrind to find where the leak appears and you can only test mallocs that you do directly. If a lib leaks because you use it wrong, rmdebug won't find it.
http://www.hexco.de/rmdebug/
Most memory profilers slow my large complex Windows application to the point where the results are useless. There is one tool that works well for finding leaks in my application: UMDH - http://msdn.microsoft.com/en-us/library/ff560206%28VS.85%29.aspx
Mtrace appears to be the standard built-in one for linux. The steps are :
set up the environment variable MALLOC_TRACE in bash
MALLOC_TRACE=/tmp/mtrace.dat
export MALLOC_TRACE;
Add #include <mcheck.h> to the top of you main source file
Add mtrace(); at the start of main and muntrace(); at the bottom (before the return statement)
compile your program with the -g switch for debug information
run your program
display leak info with mtrace your_prog_exe_name /tmp/mtrace.dat
(I had to install the mtrace perl script first on my fedora system with yum install glibc_utils )