How to find memory leaks in source code

If it is known that an application leaks memory (when executed), what are the various ways to locate such memory leak bugs in the source code of the application.

I开发者_如何学Go know of certain parsers/tools (which probably do static analysis of the code) which can be used here but are there any other ways/techniques to do that, specific to the language (C/C++)/platform?

1. compile Your code with -g flag
2. Download valgrind (if You work on Linux) an run it with --leak-check=yes option

I thinkt that valgrind is the best tool for this task.

For Windows: See this topic: Is there a good Valgrind substitute for Windows?

There's valgrind and probably other great tools out there. But I'll tell you what I do, that works very well for me, given that many times I code in environments where you can't run valgrind:

• Be sure to pair each allocation with a deallocation. I always count news or mallocs and search for the delete or free.
• If in C++ and using exceptions, try to put them paired on constructors/destructors. If you like risk, or can't put them in Ctor/dtor, be sure no exception can make the program flow not to execute the deallocation.
• Use of smart pointers and ptr containers.
• One can monitor alloc/dealloc rewriting new or installing a malloc handler. At some point, if the code runs continuously it can be obvious if the memory usage becomes stationary and doesn't grow without bounds which would be the worst case of leak.
• Be careful with containers that never shrink such as vectors. There are tricks to shrink them swapping them with an empty container.

There are two general techniques for memory leak detection, dynamic and static analysis.

In dynamic analysis, you run the code and a tool analyzes the run to see what memory has leaked at the end. Dynamic analysis tends to be highly accurate but will only correctly analyze that specific executions you do within your tool. So, if some of your leaks that only happens for certain input and you don't have a test that uses that input, dynamic analysis will not detect those leaks.

Static analysis analyzes the source code to create all possible code paths and see if a leak can occur in any of them. While static analysis is pretty good right now, it's not perfect - you can not only get false negatives (the analysis misses leaks), you can also get false positives (the tool claims you have a leak when there actually isn't one).

There are many dynamic analysis tools including such well known tools as Valgrind (open source but limited to x86 Linux and Mac) and Purify (commercial but also available for Windows, Solaris and AIX). Wikipedia has a decent list of some other dynamic analysis tools as well.

On the static analysis side, the only tool I've thought worthwhile is Coverity (commerical). Once again, Wikipedia has a list of many other static analysis tools.

Purify will do a seemingly miraculous job of doing this

Not only memory leaks, but many other kinds of memory errors.

It works by instrumenting your machine code in real time, so you don't need source or need to compile with any particular options.

Just instrument your code with Purify (simplest way to do this: CC="purify cc" make), run your program, and get a nice gui that will show your leaks and other errors.

Available for Windows, Linux, and various flavors of Unix. There's a free trial download available.

http://www.ibm.com/software/awdtools/purify

If you utilize smart pointers and keep a table of them, then you can analyze it to tell what memory you are still using. Either provide a window to view it, or more commonly, stream to a log before the program terminates.

As far as doing it manually is concerned I don't think there are any established practices. To go over the code with a fine-toothed comb, looking for news (allocs) without corresponding deletes (frees), is all that is there to it.

You can also use purify for detection of memory leak.

There aren't very many general purpose guidelines for finding memory leaks. Fortunately, there's one simple guideline for preventing most leaks, both of memory and of other resources: use RAII (Resource Acquisition Is Initialization), and they just won't happen to start with. The name is a lousy description, but if you Google on it, you should get quite a few useful hits.

Personally, I would recommend that you wrap all variables which you need to allocate/deallocate memory with the clone_ptrclass which performs all the deallocation of memory for you when it is no longer needed. Thus, you do not have to use delete. It is quite similar to auto_ptr. The major difference is that you do not have to deal with the tricky ownership transfer part. More information and code on clone_ptr can be found here.