views:

109

answers:

3

I use GNU gprof 2.15.94.0.2.2 to do profiling of my C++ program, which has large call cycles. I expected to see something like below in the call graph output as gprof's documentation indicates:

index  % time    self  children called     name
----------------------------------------
                 1.77        0    1/1        main [2]
[3]     91.71    1.77        0    1+5    <cycle 1 as a whole> [3]
                 1.02        0    3          b <cycle 1> [4]
                 0.75        0    2          a <cycle 1> [5]
                    0        0    6/6        c [6]
----------------------------------------

However, none of my <cycle as a whole> entries have any callers listed. They are all like this:

index  % time    self  children called             name
----------------------------------------------
[8]     65.6    259.55  5342.63  9334767+60122608 <cycle 2 as a whole> [8]
                133.28  2051.45  12043564+74015448    foo <cycle 2> [14]
                18.90   976.38   2379645              bar <cycle 2> [21]
...                                                                      
-----------------------------------------------

Since my cycles are quite large, it is very hard to trace the callers via individual functions in a cycle.

Can anyone tell me why the cycle callers are missing in the output, and how to make them show up?

A: 

I'm going to go so far as to call this a bug in gprof. I set up a simple example of mutually recursive functions and got the exact same behavior you did. I had functions:

int a(int n){return b(n);}
int b(int n){return c(n);}
int c(int n){return (n==0)?n:a(n-1);}

and a main():

for(int j=0; j <1000; ++j)
  for(int i=0; i < 10; ++i)
     cout << a(i);

I tried replacing the call to a() with:

int d(int n){return a(n);}

in the hopes that gprof would register a call to the cycle from d() better than the call from main(), but I got the same result.

I also replaced the cout with printf() and made a C program, with the same results of no caller listed for the cycle.

Dan Hook
A: 

Is this your main concern, or do you have a larger goal, like trying to find things you can optimize? Usually, that's why people use gprof.

gprof is what it is, but you can do better.

Mike Dunlavey
+1  A: 

Does your application use multithreading? gprof doesn't work with threads at all. Otherwise, you may very likely have hit a bug in gprof. It's bug ridden and obsolete. Better use something like oprofile or valgrind.

drhirsch