gprof2dot.py fails with KeyError exception

[GoogleCodeExporter]

What steps will reproduce the problem?

1. profile "x11perf -aa10text" using oprofile
2. run "opreport -cgf /usr/bin/Xorg -p
/lib/modules/2.6.24-16-generic/extra/  > profile"
3. run "gprof2dot.py -f oprofile ./profile"

What is the expected output? What do you see instead?
gprof2dot.py fails with the following message:

Traceback (most recent call last):
  File "./gprof2dot.py", line 1345, in <module>
    Main().main()
  File "./gprof2dot.py", line 1268, in main
    self.profile = parser.parse()
  File "./gprof2dot.py", line 830, in parse
    call = caller.calls[_function.id]
KeyError: ':vmlinux-debug-2.6.24-16-generic:signal_32.c:651:do_notify_resume'

What version of the product are you using? On what operating system?

gprof2dot.py was fetched from svn on sat 04/12/08 (v0.4)
oprofile v0.9.3
on ubuntu hardy

Please provide any additional information below.

I have attached the gzipped profile file.

Original issue reported on code.google.com by mathieu....@gmail.com on 12 Apr 2008 at 7:25

Attachments:

• profile.gz

[GoogleCodeExporter]

Mathieu, thanks for the report.

I've commited a fix to this issue, and gprof2dot now works.

But I found another issue with the profile you sent -- the resulting dot file 
is huge
and dot takes forever to produce a graph. I'll need some more time to analyze 
this,
but my guess is that due to IRQs usage or kernel preemption the call graph 
turns into
a dense spaghetti ball. I'll either need to provide a mechanism to mark IRQs, 
or a
heuristic to prune nodes and edges inside call cycles.

Original comment by Jose.R.F...@gmail.com on 14 Apr 2008 at 2:32

• Changed state: Started

[GoogleCodeExporter]

Mathieu, I've finally managed to come up with an heuristic to propagate time 
inside
recursive function cycles. The generated dot file is much smaller, and dot can 
now
produce result in a finite time. Resulting output attached.

It is now possible to make some sense out of the kernel-side call graph -- there
appears to be a lot of time spend waiting for buffers --, but it still looks a 
bit
like spaghetti. I think this is due to oprofile limitations (call stack is not 
100%
exact), and I can't see anything else that gprof2dot can do to improve the 
situation.

Original comment by Jose.R.F...@gmail.com on 28 Jun 2008 at 3:51

• Changed state: Fixed

Attachments:

• x11perf.png

[GoogleCodeExporter]

Jose, thank you very much for your time.

Original comment by mathieu....@gmail.com on 28 Jun 2008 at 11:56