Re: Looking for the big hammer
Re: Looking for the big hammer
- Subject: Re: Looking for the big hammer
- From: Ken Thomases <email@hidden>
- Date: Mon, 27 Oct 2008 18:45:50 -0500
On Oct 27, 2008, at 4:00 PM, Chilton Webb wrote:
I have a particular problem that is buried deep in layers of logic.
Worse, it only happens on some systems, and only after they've been
running for a long time. I know it's extremely heavy handed, but I
want to know every single function call in my app that happens from
one point to another, even if it takes an hour to generate, and is
hundreds of megabytes in size.
It looks like dtrace might do it. Does anyone have a dtrace script
that returns a mountain of data like this?
When you say "every single function call in my app", do you mean the
functions that are defined in your app that are called, or all
functions anywhere that are called by your app?
If you try to instrument every single function entry and return for
your app and every framework and library to which it links, I think
that'll overwhelm DTrace. Also, although you think you want all that
info, I suspect it will overwhelm your ability to analyze it.
In theory, you would use something like this:
sudo dtrace -F -n 'pid$target:::entry, pid$target:::return {}' -c /
path/to/YourApp.app/Contents/MacOS/YourApp
If you want to limit it to just the functions in your app, you'd
specify your app as the module in the probe specifiers:
sudo dtrace -F -n 'pid$target:YourApp::entry, pid
$target:YourApp::return {}' -c /path/to/YourApp.app/Contents/MacOS/
YourApp
(You can use -p <pid> rather than -c <command> to trace an already
running process.)
The above commands use the -F switch and probes on function entry and
return to get a formatted call tree. That's nice for simple cases,
but tends to fall down in real-world tracing. The problem is that
DTrace gets data from the kernel asynchronously and, if a process or
thread migrates from one CPU core to another, it may be out of order.
That messes up the call tree.
To address that, I've sometimes used a technique where I manually
trace a bunch of explicit data about function entry and return,
including which thread it's on, call depth, a per-thread sequence
number, etc. I then have DTrace write this to a tab-delimited file,
without attempting to format it with -F. Post-processing of the
output file allows one to recreate the call tree for each thread.
Here's a sample DTrace script that illustrates the technique:
============== begin script ==============
#pragma D option quiet
self int order, level;
pid$target:YourApp::entry,
pid$target:YourApp::return
{
printf("%s\t%s\t%s\t%lld\t%d\t", probemod, probefunc, probename,
(long long)tid, ++self->order);
}
pid$target:YourApp::entry
{
printf("%d\n", self->level++);
}
pid$target:YourApp::return
{
printf("%d\n", --self->level);
}
============== end script ==============
Good luck,
Ken
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden