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


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

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.


  • Maynard Johnson

    Maynard Johnson - 2013-10-24

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

  • Maynard Johnson

    Maynard Johnson - 2014-01-02
    • status: open --> open-fixed
    • Group: -->
  • Maynard Johnson

    Maynard Johnson - 2014-01-02

    Received positive feedback on the attached patch from a couple of community members, so I committed it upstream today.

  • Maynard Johnson

    Maynard Johnson - 2014-09-11
    • Status: open-fixed --> closed

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks