How to get a callstack from oprofile output?

Question

I'm so confused. I don't know if oprofile can even provide a stack trace from a profiling report. I've been reviewing the oprofile manual and it only refers to stacktraces by saying that they can be logged, but it doesn't give an example for how to do so.

Here's my test.cpp

#include <iostream>                              
#include <unistd.h>                              
using namespace std;                             

void test(){                                     
    for (int x = 0; x < 100000; x++) cout << ".";
    sleep(1);                                    
    cout << endl;                                
};                                               

int main(int argv, char** argc){                 
    for (int x = 0; x < 120; x++) test();        
    return 0;                                    
}                                                

Here's the command I used to compile it:

g++ -g -Wall test.cpp -o test

And, here's my perf.sh script (running on RHEL 6.2 in a VM):

#!/bin/bash -x
sudo opcontrol --no-vmlinux                                                 
sudo opcontrol --reset                                                      
sudo opcontrol --start --separate=library,thread --image=$HOME/test
sudo opcontrol --callgraph=10                                               
sudo opcontrol --status                                                     
read -p "Press [Enter] key to stop profiling"                                                                       
sudo opcontrol --dump || exit 1                                             
sudo opreport --demangle=smart \                                            
              --merge=all \                                                 
              --symbols \                                                   
              --callgraph \                                                 
              --global-percent \                                            
              --output-file=perf.out                                        
sudo opcontrol --shutdown                                                   
sudo opcontrol --reset                                                      

Here's the report that I'm getting, at this time:

CPU: CPU with timer interrupt, speed 0 MHz (estimated)                            
Profiling through timer interrupt                                                 
samples  %        app name                 symbol name                            
-------------------------------------------------------------------------------   
14       43.7500  libstdc++.so.6.0.13      /usr/lib64/libstdc++.so.6.0.13         
  14       43.7500  libstdc++.so.6.0.13      /usr/lib64/libstdc++.so.6.0.13 [self]
-------------------------------------------------------------------------------   
11       34.3750  libc-2.12.so             fwrite                                 
  11       34.3750  libc-2.12.so             fwrite [self]                        
-------------------------------------------------------------------------------   
5        15.6250  libc-2.12.so             _IO_file_xsputn@@GLIBC_2.2.5           
  5        15.6250  libc-2.12.so             _IO_file_xsputn@@GLIBC_2.2.5 [self]  
-------------------------------------------------------------------------------   
2         6.2500  libc-2.12.so             __strlen_sse42                         
  2         6.2500  libc-2.12.so             __strlen_sse42 [self]                
-------------------------------------------------------------------------------   

And, my question: How can I get stack traces to show up in the profiling report?

Answer 1

(this is a bit late, but this might help someone else)

Because you're profiling in timer mode (which is the default behavior on some CPUs), the backtracing might be disabled in your kernel (which version appears to be 2.6.32, since you're on RHEL 6.2).

You can try to:

1. use hardware counters
2. have a look at the history of the kernel part of oprofile, if there is indeed a limitations in your kernel version, this may have been fixed
3. update your kernel

I faced the same issue with the same kernel release, but since I'm on ARM, my quick-fix won't work (this is the patch to apply in this case).