C Memory Scavenger（C、C++内存检测、收集工具）

http://www.matexdata.com/CMemScav/index.htm
Introduction
Got problems with memory leaks in C code for Windows and/or Solaris? Now version 2.0 of C Memory Scavenger is released.
C Memory Scavenger is a combined tool for locating memory allocations as well as for fixing leaks without detailed knowledge about the source code. Traditionally, to fix such leaks, you have to understand the code quite well, and insert free-commands at precise places. C Memory Scavenger is a good tool for such work. However, many times you have limited knowledge about how the code works, and not much time to spend on code study. This is where C Memory Scavenger  has its key advantage over its competitors. It can work as a semi-automatic garbage collector, with only a limited support from the user. This tool works also for C++ code but it does not take care of memory allocated/deallocated with new/delete. To cover these operators, you need to have access to, and recompile the code where new/delete are defined in terms of calls to malloc/free. For a complete list of which memory allocation functions are supported, seeThe CMemScav Library.
The tool is divided into two parts:
A Windows program - called the Monitor - with which you can communicate with your application, in terms of pausing it, asking for present memory allocations at any time, and your application can report such information to the Monitor from any given point in the source code. With this as a base, you can create code to be inserted into your application to solve your memory leaks, although, this program is not necessary to use the second tool.
A dynamic library (a ".dll" file in the Windows case, a ".so" file in the Solaris case) together with some header files, to be compiled and linked together with your application. This library keeps track of all memory allocations and deallocations, and can report memory status to the Monitor or the console, and is the core of C Memory Scavenger. It can clear outstanding memory allocations in a number of ways, which is the "garbage collection" part. The Monitor is a tool for creating such calls, and in a way, is the "semi-automatic" part.
These two parts communicate with each other over IP, using socket communication. Therefore they do not need to be run at the same computer (which would be difficult in the Solaris case), but they need a common network communication.
A screen shot of the Monitor is shown below. An application was run on the same PC, using 250 threads. Each thread called malloc, calloc, realloc, strdup, wcsdup, mbsdup, GlobalAlloc, LocalAlloc, HeapAlloc, and HeapRealloc a number of times. They allocated a random number of bytes and "forgot" to call free, GlobalFree, LocalFree, and HeapFree respectively, about 1% of the time. The Monitor showed every second a summary of the allocations, both as values in a table and as a diagram over time, by asking the application every second to report back this data. At the end, the application took the initiative and reported a detailed list over all outstanding memory allocations, by calling the function CMemScavShowList() in the library. This call was inserted in the application C:\CMemScav\src\StressTest.c at line 597, which can be seen in the screen shot's yellow text fields.
Finally, the Monitor created the library call "CMemScavFreeAll();" based on the detailed list of allocations. Inserting this call at line 597 in the source code would clear off all the "forgotten" allocations at this point in the code. This call could normally be put at the end of any application, clearing off all outstanding memory. However, many times you also need to do a more fine tuned cleaning earlier in the code. How this may be done, is the story in the next few pages.

Screen shot of the Monitor