Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

#256 opreport from 'operf --callgraph' profile shows incorrect recursive calls

None
open-fixed
None
5
2014-01-02
2013-10-24
Maynard Johnson
No

When you collect a callgraph profile with operf, the opreport output incorrectly implies recursive calls. For example, my simple memcpy testcase does the following:
main -> do_my_memcpy -> memcpy (libc)

The part of the callgraph report that focuses on do_my_memcpy looks like the following:

  4757     50.0000  memcpyt                  do_my_memcpy
  4757     50.0000  memcpyt                  main
4757      6.3185  memcpyt                  do_my_memcpy
  4757     49.9842  memcpyt                  do_my_memcpy
  4757     49.9842  memcpyt                  do_my_memcpy [self]
  3         0.0315  no-vmlinux               /no-vmlinux

So it appears that do_my_memcpy calls itself, which it does not do.

If I use 'perf record' to get a callgraph profile, the 'perf report' looks like the following:

 6.88%  memcpyt  memcpyt           [.] do_my_memcpy               
        |
        --- do_my_memcpy
            main
            __libc_start_main

So here, too, it seems to me that do_my_memcpy calls do_my_memcpy. But when I reported this issue to perf/perf_events kernel developers, they don't think it's a problem. I didn't push it because we can easily handle this in operf by dropping the first address in the callchain (since it's repeated in the second callchain entry) that the kernel returns to us.

Discussion

  • NOTE: With the opreport callgraph output as is, the gprof2dot.py script also indicates recursive calls.

     
    • status: open --> open-fixed
    • Group: -->
     
  • Received positive feedback on the attached patch from a couple of community members, so I committed it upstream today.