how to use gdb to locate memory leak in source

[Rob Veenman]

I use gdb to find memory leaks in my C++ program. It comes up with a list of (mainly) constructors like:

1 3500 125 0x40d7f698 operator new [](unsigned long)()
2 1152 32 0x40edf160 operator new(unsigned long)()
3 216 6 0x40edec20 operator new(unsigned long)()
4 180 5 0x40edf190 operator new(unsigned long)()
7 144 4 0x40edf1c0 operator new(unsigned long)()

I like to know exactly in which source this constructor was called so I can assess the code and fix the leak.
However, just this constructor info is not specific enough for me to relate that to a specific source file. The program I am dealing with consist of hundreds of source files in many directories, and in a lot of different places constructors are called.

Also the 'info leak' output gives me address info, but if I interpret the data correctly it is a heap address and not a text address. So putting a breakpoint on this address so I can do a backtrace does not work because the program is never stopped by the breakpoint.

Does anybody have good idea's how I can set a smart breakpoint so I can get more detailed info in what source the leaks occur?

[A. Clay Stephenson]

You need to compile all the source with the "-g" option to put debugging data into the objects and executable. You also need supply -d dir1 -d dir2 to gdb so that it knows where to look for your source files.

[Rob Veenman]

I compiled everything with -g (otherwise 'info leak' does not work). I can get all the sources across from our compile box to our run environment or use nfs mount. But that still does not tell me where (= in what source and line number) memory is allocated but not freed (correct me if I am wrong here).
'info leaks' only gives me the 'operator new' info which is not sufficient for me to find a unique source.
Is there a way gdb can give me more details? Can I make use of the address in the 'info leak' output?

[Ermin Borovac · Accepted solution]

Please try the following.

(gdb) info leaks

This should print out more detailed leak report.

(gdb) info leaks
Scanning for memory leaks...


1000 bytes leaked in 1 blocks

No. Total bytes Blocks Address Function
0 1000 1 0x40429c30 operator new [](unsigned long)()

(gdb) info leaks 0
1000 bytes leaked at 0x40429c30 (100.00% of all bytes leaked)
in operator new [](unsigned long) ()
in f(void) () at test.C:4
in main () at test.C:8
in _start ()

[Rob Veenman]

info leaks is giving me exaclty what I was looking for.