38

I am using google's heap checker to track down a memory leak. It gives me a stack trace such as:

Leak of 21 bytes in 1 objects allocated from:                                                                                                                                                               
    @ 0xf6088241                                                                                                                                                                                               
    @ 0xf60890d2                                                                                                                                                                                               
    @ 0xf6089246                                                                                                                                                                                               
    @ 0x8054781                                                                                                                                                                                                
    @ 0x8054862                                                                                                                                                                                                
    @ 0xf684ee76                                                                                                                                                                                               
    @ 0xf684f343                                                                                                                                                                                               
    @ 0x804be4c                                                                                                                                                                                                
    @ 0x80544f6                                                                                                                                                                                                
    @ 0xf5e52bb6                                                                                                                                                                                               
    @ 0x804b101  

How do I determine what functions/lines of code these memory addresses correspond to?

flumpb
  • 1,707
  • 3
  • 16
  • 33
Nathaniel Flath
  • 15,477
  • 19
  • 69
  • 94
  • 3
    I am surprised Google's heap checker does not do this conversion for you. Are you sure you compiled with "-g"? (Also, take a look at the [addr2line command](http://sourceware.org/binutils/docs/binutils/addr2line.html)) – Nemo Oct 03 '11 at 19:04
  • Any symbol type question: http://stackoverflow.com/questions/762628/gdb-getting-a-symbol-name-from-a-memory-address – Ciro Santilli OurBigBook.com Jul 17 '15 at 09:10

3 Answers3

63

Use info symbol gdb command. 16 Examining the Symbol Table.

info symbol addr

Print the name of a symbol which is stored at the address addr. If no symbol is stored exactly at addr, gdb prints the nearest symbol and an offset from it:

(gdb) info symbol 0x54320
_initialize_vx + 396 in section .text

This is the opposite of the info address command. You can use it to find out the name of a variable or a function given its address.

For dynamically linked executables, the name of executable or shared library containing the symbol is also printed:

(gdb) info symbol 0x400225
_start + 5 in section .text of /tmp/a.out
(gdb) info symbol 0x2aaaac2811cf
__read_nocancel + 6 in section .text of /usr/lib64/libc.so.6
Yi Jiang
  • 49,435
  • 16
  • 136
  • 136
ks1322
  • 33,961
  • 14
  • 109
  • 164
  • So, after I got a list of info commands, and figured out that `info address` doesn't lookup address, turned out there's also a `info symbol` command, which doesn't query a symbol. – Hi-Angel Jul 17 '16 at 17:35
12

The original question asked how to do this in GDB:

# NOT what you want; note the lack of '*':
(gdb) info symbol 0xfde09edc
blah() + 388 in section .text of /tmp/libblah.so

# IS what you want; note the presence of '*':
(gdb) info line *0xfde09edc
Line 91 of "blah.cc"
   starts at address 0xfde09ebc <blah()+356>
   and ends at 0xfde09ee4 <blah()+396>

The * is necessary for info line and shouldn't be used for info symbol.

You can also use the disassemble command with its /m flag:

(gdb) disassemble /m 0xfde09edc

... though it's rather verbose and info line gives exactly what was requested.

Brian Vandenberg
  • 4,011
  • 2
  • 37
  • 53
  • 3
    Please note that `/m` modifier is deprecated in favor of `/s` (appeared in gdb 7.11). Anyway, you can use much less verbose output of `x/i 0xfde09edc` instead of disassembling the whole function. – Ruslan Jul 12 '17 at 19:32
2

Assuming your binary has debug information g++ -g you may be able to use x/ to get the info, I know that works for vtables.

x/<num>xw to print <num> hex words of memory, and gdb will annotate the left side with information about what's at the address.

Mark B
  • 95,107
  • 10
  • 109
  • 188