When using perf report
, I don't see any symbols for my program, instead I get output like this:
$ perf record /path/to/racket ints.rkt 10000
$ perf report --stdio
# Overhead Command Shared Object Symbol
# ........ ........ ................. ......
#
70.06% ints.rkt [unknown] [.] 0x5f99b8
26.28% ints.rkt [kernel.kallsyms] [k] 0xffffffff8103d0ca
3.66% ints.rkt perf-32046.map [.] 0x7f1d9be46650
Which is fairly uninformative.
The relevant program is built with debugging symbols, and the sysprof
tool shows the appropriate symbols, as does Zoom, which I think is using perf
under the hood.
Note that this is on x86-64, so the binary is compiled with -fomit-frame-pointer
, but that's the case when running under the other tools as well.
This post is already over a year old, but since it came out at the top of my Google search results when I had the same problem, I thought I'd answer it here. After some more searching around, I found the answer given in this related StackOverflow question very helpful. On my Ubuntu Raring system, I then ended up doing the following:
-g
(fairly obvious, you need debug symbols)Run perf
as
record -g dwarf -F 97 /path/to/my/program
This way perf
is able to handle the DWARF 2 debug format, which is the standard format gcc
uses on Linux. The -F 97
parameter reduces the sampling rate to 97 Hz. The default sampling rate was apparently too large for my system and resulted in messages like this:
Warning:
Processed 172390 events and lost 126 chunks!
Check IO/CPU overload!
and the perf report
call afterwards would fail with a segmentation fault. With the reduced sampling rate everything worked out fine.
perf.data
file has been generated without any errors in the previous step, you can run perf report
etc. I personally like the FlameGraph tools to generate SVG visualizations.Other people reported that running
echo 0 > /proc/sys/kernel/kptr_restrict
as root can help as well, if kernel symbols are required.