perf report failing with error "data field size is 0 which is unexpected. Was 'perf record' command properly terminated?" - profiling

I ran perf record with following command:
perf record -g -o perf.data.lds "my executables with arguments"
Program ran fine and I can see "perf.data.lds" file generated of non-zero size.
-rw------- 1 sjain medrd 364855672 Feb 18 12:45 perf.data.lds
But when I try to open the perf data using "perf report -i perf.data.lds" command I am getting following error:
WARNING: The perf.data.lds file's data size field is 0 which is unexpected.
Was the 'perf record' command properly terminated?
Any guidance why this might be happening and how I can resolve this problem will be helpful.

Related

Problems with using gperftools on Mac OS X

I have found several conflicting answers over this topic. This blog post requires libuwind, but that doesn't work on Mac OS X. I included #include <google/profiler.h> in my code, however my compiler (g++) could not find the library. I installed gperftools via homebrew. In addition, I found this stackoverflow question showing this:
Then I ran pprof to generate the output:
[hidden ~]$ pprof --text ./a.out cpu.profile
Using local file ./a.out.
Using local file cpu.profile.
Removing __sigtramp from all stack traces.
Total: 282 samples
107 37.9% 37.9% 107 37.9% 0x000000010d72229e
16 5.7% 43.6% 16 5.7% 0x000000010d721a5f
12 4.3% 47.9% 12 4.3% 0x000000010d721de8
...
Running that command (without any of the prior steps) gets me this:
[hidden]$ pprof --text ./a.out cpu.profile
Using remote profile at ./a.out.
Failed to get the number of symbols from http://cpu.profile/pprof/symbol
Why does it try to access an internet site on my machine and a local file on his/hers?
Attempting to link lib profiler as a dry run with g++ gets me:
[hidden]$ g++ -l libprofiler
ld: library not found for -llibprofiler
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I have looked at the man pages, the help option text, the official online guide, blog posts, and many other sources.
I am so confused right now. Can someone help me use gperftools?
The result of my conversation with #osgx was this script. I tried to clean it up a bit. It likely contains quite a few unnecessary options too.
The blog post https://dudefrommangalore.wordpress.com/2012/02/09/profiling-c-code-using-google-performance-tools/ "Profiling C++ code using Google Performance Tools" 2012 by dudefrommangalore missed the essential step.
You should link your program (which you want to be profiled) with cpu profiler library of gperftools library.
Check official manual: http://goog-perftools.sourceforge.net/doc/cpu_profiler.html, part "Linking in the Library"
add -lprofiler to the link-time step for your executable. (It's also probably possible to add in the profiler at run-time using LD_PRELOAD, but this isn't necessarily recommended.)
Second step is to collect the profile, run the code with profiling enabled. In linux world it was done by setting controlling environment variable CPUPROFILE before running:
CPUPROFILE=name_of_profile ./program_to_be_profiled
Third step is to use pprof (google-pprof in ubuntu world). Check that there is not-empty name_of_profile profile file generated; it there is no such file, pprof will try to do remote profile fetch (you see output of such try).
pprof ./program_to_be_profiled name_of_profile
First you need to run your program with profiling enabled.
This is usually first linking your program with libprofiler and then running it with CPUPROFILE=cpu.profile.
I.e.
$ CPUPROFILE=cpu.profile my_program
I think that later step is what you have been missing.
The program will create this cpu.profile file when it exits. And then you can use pprof (preferably from github.com/google/pprof) on it to visualize/analyze.

How to get a coredump from `abrt`

I'm running Fedora 23, and just recently discovered that abrt handles the coredumps from my crashed application, and places all kind of stuff in /var/spool/abrt/ccpp-date-pid. Is there a command to fetch a coredump from abrt, without manually copying it from the indicated folder? Or could I have abrt feed the coredump to gdb, and also load the binary?
I would prefer not to change /proc/sys/kernel/core_pattern.
I'm thinking somehting along the lines of:
$ cc -g -o foo main.c
$ ./foo
segmentation fault (core dumped)
$ abrt-magic d55ba08dd0535a223d4a7...
(gdb) # time to do post mortem debugging...
Where of course abrt-magic would be replaced with some command
Not quite what you want, but you can use abrt-cli list to list the ids and abrt-cli info -d on a given id to get the backtrace. You need to configure abrtd to save info for non-package dumps with:
sed -i 's/ProcessUnpackaged = no/ProcessUnpackaged = yes/' /etc/abrt/abrt-action-save-package-data.conf
You can also get an "old-fashioned" core dump in the usual current directory of the process, if the ulimit -c value allows it, by setting
MakeCompatCore = yes
in config file /etc/abrt/plugins/CCpp.conf.

"Operation not permitted" running hello world binary compiled w/ clang++ on El Capitan

Background
I created a simple Hello World C++ program:
#include <iostream>
using namespace std;
int main() {
cout << "Hello World!" << endl;
return 0;
}
And compiled it with clang++ like so (g++ points to clang++ on OS X apparently):
g++ helloworld-cpp.cpp
This produces an executable, a.out. Running it at the prompt causes bash to throw the error Operation not permitted, as shown:
$ ./a.out
-bash: ./a.out: Operation not permitted
Things I've Tried
Verifying the file has execute permissions, and no attributes or flags that would prevent it from running, using ls -leO:
-rwxr-xr-x 1 monarch staff - 15212 Jan 1 13:51 a.out
Disabling "System Integrity Protection" using csrutil disable from the Recovery OS terminal, rebooting, recompiling, and running a.out. The same error messages results.
Question
Are there any other restrictions that could prevent binaries I compile on Mac OS X from running?
Figured it out.
My code was on an encrypted sparseimage, which had the quarantined attribute set on it. I checked this by running mount like so (see attributes on /Volumes/work):
$ mount
/dev/disk0s2 on / (hfs, local, journaled)
/dev/disk2s2 on /Volumes/work (hfs, local, nodev, nosuid, journaled, noowners, quarantine, mounted by monarch)
The actual sparseimage is located in my home folder, titled work.sparseimage. I removed the quarantine attribute like so:
$ xattr -d com.apple.quarantine work_personal.sparseimage
I then unmounted (ejected) the image, then re-mounted it, recompiled the file and it executed without the error.
Special thanks to #Mark Setchell for asking me in the question's comments if noexec was set on the drive, and to everyone else for their suggestions.

GDB - unable to get command history working

I'm new to GDB and can't get the command history (auto complete/up arrow to old commands working).
At my root I have a .gbd_init file (and I also have an identical file in my working directory):
set history save
set history filename ~/.gbd_history
set history on
set history expansion on
I also have an empty .gbd_history file at my root.
In GBD 'show history' gives:
(gdb) show history
expansion: History expansion on command input is on.
filename: The filename in which to record the command history is
"/home/jenny/C_Programs/CS575_Algorithms/HW3/Problem1/.gdb_history".
save: Saving of the history record on exit is on.
size: The size of the command history is unlimited.
(gdb)
But the GBD command 'show commands' yields nothing and the up-arrows and tab don't do anything.
The .gbd_history file exists but is empty.
jenny#jennys-virtual-machine ~/C_Programs/CS575_Algorithms/HW3/Problem1 $ ls -ls .gbd*
0 -rwxrwxrwx 1 jenny jenny 0 Oct 1 22:16 .gbd_history
4 -rwxrwxrwx 1 jenny jenny 94 Oct 1 22:01 .gbdinit
What am I missing?
Thanks for any help. Typing in each command is getting old fast.
Jenny
At my root I have a .gbd_init file (and I also have an identical file
in my working directory):
You have misspelled gdb init file name. It should be named .gdbinit. .gbd_init is not get executed by gdb and history saving is not turned on.
Your .gdbinit script obviously is not executed, as you can see from your gdb_history filename, which has it's default value (gdb_history in current directory).
Try executing this init script in your current directory with gdb -x .gdbinit, as it may be disabled by default. At least my gdb wants me to set some kind of auto-load safe-path before it will allow loading of init scripts residing outside of home directory. See details here.
If you are looking to use history only to not have to repeat commands, you should probably just write a script with all those commands, and execute it with gdb -x script etc.
And surely check this SO thread on how to enable command history easily.

How to associate valgrind with a running process?

I have a binary called "ifmFuseHandler" which is invoked by a shell-script something like this:
su - $USER -c "cd $DIR_INDEX;valgrind --leak-check=full ifmFuseHandler $IFM_SINGLE_THREAD -o allow_other $IFM_MOUNT"
But the problem is, i can see the valgrind logs only once, when the control hits this line of shell, and post that even though the ifmFuseHandler is up and running, valgrind does not provide any profiling info.
So, as you can see below, but no further logging:
insite1#POC-Messaging1:/opt/insiteone/log> ps -ef | grep ifmFuseHandler
insite1 622 1 0 04:19 ? 00:00:02 valgrind --leak-check=full ifmFuseHandler -o allow_other /opt/insiteone/fuse-mount
insite1 3225 26014 0 04:32 pts/2 00:00:00 grep ifmFuseHandler
You need to adjust your shell-script to explicitly log the output of valgrind to a file as described here.
If your program is invoked multiple times, try using a filename with the PID, as described in the usage of --log-file=<filename> here.
Just make sure your output file is in an easily readable location.