Re: DTrace Questions
Re: DTrace Questions
- Subject: Re: DTrace Questions
- From: Ken Thomases <email@hidden>
- Date: Sat, 8 May 2010 00:41:37 -0500
On May 7, 2010, at 9:31 AM, Eric Gorr wrote:
> ~ $sudo dtrace -n 'pid653:MyApp::entry { printf( "%s", execname ) }'
> dtrace: description 'pid653:MyApp::entry ' matched 7 probes
>
> However, it does not seem to be listing any entry or exit probe for myRandomMethod.
The above command doesn't list the probes.
> What the 7 probes it did match, I am not sure as it just seemed to hang after printing out that it matched 7 probes.
It didn't hang. It's tracing. When probes fire, it will print the relevant messages. You press Control-C to terminate tracing.
> What did seem to work was doing:
>
> ~ $sudo dtrace -l -n 'pid1005:MyApp::entry'
> ID PROVIDER MODULE FUNCTION NAME
> 26632 pid1005 MyApp start entry
> 361570 pid1005 MyApp main entry
> 361588 pid1005 MyApp -[MyAppAppDelegate myRandomMethod] entry
> 361609 pid1005 MyApp -[MyAppAppDelegate applicationDidFinishLaunching:] entry
> 361628 pid1005 MyApp -[MyAppAppDelegate window] entry
> 361647 pid1005 MyApp -[MyAppAppDelegate setWindow:] entry
> 361668 pid1005 MyApp stub helpers entry
Right. That command does list the matching probes and there are the 7 matched probes.
> I then build and ran the release build and got the same basic results:
> This surprised me a bit. The Release build should have all of the symbols stripped from it and yet the method names are still available. I figure this is expected, but it did surprise me.
The dynamic nature of Objective-C means that information about classes and methods (and some other things, like protocols and properties) are required at run-time. Therefore, there's no way to fully strip that information without rendering the program inoperative.
> ~ $sudo dtrace -l -n 'pid1247:myApp::return'
> dtrace: invalid probe specifier pid1247:myApp::return: failed to create return probe for '-[NNASoundManager initializeSounds]': Invalid argument
>
> However, this error was only seen with a release build. With the Debug build, I get all of the expected output.
>
> Any idea why this error might be generated?
That's an odd one. Never seen that before. You should look into using the 'objc<n>' provider. It works a lot like the 'pid<n>' provider, but is for Objective-C methods. It's documented in the DTrace man page.
Also, just so you know, you can specify probes like the following, which I find less tedious when probing different processes sequentially:
dtrace -n 'pid$target:MyApp::entry { ... whatever ... }' -p <pid>
That is, you can use '$target' in the probe specifier and pass the PID via the '-p' option.
Regards,
Ken
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden