Tool for detecting memory leaks [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.

---

Want to improve this question? Update the question so it focuses on one problem only by editing this post.

Closed 8 years ago.

Improve this question

How do memory leak detection tools like purify and valgrind work?

How can I design and implement my own such tool?开发者_Python百科

---

Such tools usually instrument the exeutable with their own code. for instance they replace every call to malloc() and free() with their own functions which allows them to follow every allocation.

In Visual Studio this can be done automatically using just the C Runtime Library using functions from the family of _CrtDumpMemoryLeaks()

---

For basic leak detection you just need to hook into low level memory allocation routines, e.g. by patching malloc/free. You then track all allocations and subsequently report any that have not been freed at an appropriate point, e.g. just prior to exit.

---

For actual work, valgrind works quite well. It detects invalid read/write and memory leaks.

For hobby project, you can create your own memory management module which keeps track of various pointer allocation and its usage. If you don't see some mem location being used for long time, it might be a leak.

---

You can look for some BSD implementations of memory management/profiling tools for examples of code. For instance http://code.google.com/p/google-perftools/wiki/GooglePerformanceTools

---

I am developing this tool: Deleaker.

Sure, the obvious idea is to hook all functions that do allocations and deallocations. That's not only malloc and free, rather HeapAlloc / HeapFree (if we are talking about Windows platform) because modern VC++ versions (after VC 6.0) just redirect malloc / free to winapi's HeapAlloc / HeapFree.

For each allocation a stack is saved and an object is saved. On each deallocation the object is freed. At a first glance, it's so simple: just store a list of allocated objects and remove an object on deallocation hook.

But there are tricky parts:

• Speed

You need to maintain a list of allocated objects. If you add/remove an object in each hooked function, the process is being executing toooo slooow. That seems to be a common problem of such tools.

• Stack Trace

Using dbghelp.dll function to get stack trace takes a lot of time. You have to get stack entries faster: for example by manual reading of process memory.

• False positives

Some leaks are produced by system DLLs. If you show all of them, you got a tons of leaks, but user can't "solve" it: he/she doesn't have access to its source code, and can't prevent executing this code. It's impossible to stop this leaks. Some of them are single allocations at a system dll's entry point, so it's not a real leak (a good question, what's the leak at all?). How to recognize those leaks that must be shown? A good filtering is an answer.

Hope this helps.