You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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
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
Original issue reported on code.google.com by
mathieu....@gmail.com
on 12 Apr 2008 at 7:25Attachments:
The text was updated successfully, but these errors were encountered: