LeakTracer－适用于Linux、Solaris和HP-UX下跟踪和分析C++程序中的内存泄漏，同时也可以将问题直接定位到源代码。
简要介绍下LeakTracer:
dmalloc 只能查看gcc编译之后的问题代码的内存地址，但是这往往不是你所想要看到的，
LeakTracer提供了代码级别的提示。
英文详细介绍如下：
LeakTracer is a small tool I wrote when checking a C++ program for memory
leaks. I couldn't get dmalloc to display what I wanted, and I just saw the
__builtin_return_address gcc-extension mentioned.
To use LeakTracer, run your program using the provided LeakCheck script. It
uses the LD_PRELOAD feature to "overlay" some functions on top of your
functions (no recompile needed). If your platform does not support LD_PRELOAD,
you can add the LeakTracer.o object file to the objects in your Makefile and
run your application.
LeakTracer uses gdb to print out the exact line where the memory was allocated
and not freed - this of course means you have to free all dynamically
allocated data. LeakTracer also overrides the global operator new and operator
delete - this will give problems if you override them as well.
使用预览：
LeakTracer traces only new/new[] and delete calls - it does not look at
malloc/free/realloc.
Here is some example output:
Gathered 8 (8 unique) points of data.
(gdb)
Allocations: 1 / Size: 36
0x80608e6 is in NullArcableInstance::NullArcableInstance(void) (Machine.cc:40).
39 public:
40 NullArcableInstance() : ArcableInstance(new NullArcable) {}
Allocations: 1 / Size: 8
0x8055b02 is in init_types(void) (Type.cc:119).
118 void init_types() {
119 Type::Integer = new IntegerType;
Allocations: 1 / Size: 132 (new[])
0x805f4ab is in Hashtable::Hashtable(unsigned int) (ea/h/Hashtable.h:15).
14 Hashtable (uint _size = 32) : size(_size), count(0) {
15 table = new List [size];
[...]
例子：
~/p/arc# ea/LeakTracer/leak-analyze ./arc
Gathered 8 (8 unique) points of data.
(gdb)
Allocations: 1 / Size: 36
0x80608e6 is in NullArcableInstance::NullArcableInstance(void) (Machine.cc:40).
39 public:
40 NullArcableInstance() : ArcableInstance(new NullArcable) {}
Allocations: 1 / Size: 8
0x8055b02 is in init_types(void) (Type.cc:119).
118 void init_types() {
119 Type::Integer = new IntegerType;
Allocations: 1 / Size: 132 (new[])
0x805f4ab is in Hashtable<NativeCallable, String, false, true>::Hashtable(unsigned int) (ea/h/Hashtable.h:15).
14 Hashtable (uint _size = 32) : size(_size), count(0) {
15 table = new List<E, own> [size];
还有还有例2：
You should then run leak-analyze, since looking at the raw leak.out file will
not help you much. To run leak-analyze, you need Perl as well as gdb
installed (any version of gdb will do). For example:
leak-analyze myprog leak.out
You don't have to specify the leak.out filename if you just use the default
one. leak-analyze will run gdb on the file, sending it a number of commands
that will show the source lines with the memory leaks.
leak-analyze should show you something like this:
Gathered 2 (2 unique) points of data.
#-- Alloc: Different allocation schemes
alloc here :0x80485b7 is in main (test.cc:6).
5
6 int *wrong = new int[10];
..free here :0x80485d9 is in main (test.cc:11).
11 delete wrong;
#-- Leak: Allocations: 1 / Size: 168
0x8048593 is in main (test.cc:3).
2 int main() {
3 int *array = new int [42] ;
#-- Leak: Allocations: 1 / Size: 4
0x80485a5 is in main (test.cc:4).
3 int *array = new int [42] ;
4 int *foo = new int;
This means that total of two allocations happened, in two different places.
First a delete error is shown: you allocated some memory using new[] but you
freed it using delete. leak-analyze will show where you allocated the memory and where you freed it.
Afterwards each allocation is shown in turn. There was 1 allocation from this
line of code (test.cc:3), and it was 168 bytes in size. Note that of the two
lines of code shown, it's the bottom one that created the allocation.
That's all there is to it - now you should find those memory leaks, fix them
and rerun Leak tracer.