On May 8, 2010, at 1:41 AM, Ken Thomases wrote:
On May 7, 2010, at 9:31 AM, Eric Gorr wrote:
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.
While this is certainly true, it does not apply to this case.
If you run the release build and then execute
sudo dtrace -l -n 'pid40333:dtracetest::entry'
The result will be:
~ $sudo dtrace -l -n 'pid40333:dtracetest::entry'
Password:
ID PROVIDER MODULE FUNCTION NAME
dtrace: failed to match pid40333:dtracetest::entry: No probe matches description
i.e. No entry probes are found...not even for my Objective-C methods.
nm reports:
~ $nm /Users/ericgorr/Desktop/dtracetest/build/Release/dtracetest.app/Contents/MacOS/dtracetest U _NSApplicationMain U _OBJC_CLASS_$_NSObject U _OBJC_METACLASS_$_NSObject 0000000100000000 A __mh_execute_header U __objc_empty_cache U __objc_empty_vtable U _exit U _objc_msgSend U dyld_stub_binder
Now, perhaps, if I changed the provider or something to be the objective-c one, it would list my objective-c methods, but I am uncertain how to verify that. If you happen to know, I would be interested in learning about it.
The reason why I was getting probes back on a Release build before is because dtrace uses spotlight to search for dSym's for your application and can use the dSym file to automatically generate entry and return probes. You can easily verify this by building the project and generating the dSym file. dtrace -l will report back entry and return probes (among some others) now. And, of course, trashing the dSym file will return it back to the state where the probes can no longer be found. One can, of course, place the dSym file in a folder that won't be indexed by Spotlight to prevent dtrace from locating it. Interesting stuff and no longer surprises me now that I understand what is happening. :-)
Of course, if you run the debug build, where all of the symbols haven't been stripped from it, you will get the expected:
~ $sudo dtrace -l -n 'pid42589:dtracetest::entry' Password: ID PROVIDER MODULE FUNCTION NAME 24376 pid42589 dtracetest start entry 24377 pid42589 dtracetest main entry 24378 pid42589 dtracetest -[dtracetestAppDelegate myMethod:] entry 24379 pid42589 dtracetest -[dtracetestAppDelegate applicationDidFinishLaunching:] entry 24380 pid42589 dtracetest -[dtracetestAppDelegate buttonPushed:] entry 24381 pid42589 dtracetest -[dtracetestAppDelegate window] entry 24382 pid42589 dtracetest -[dtracetestAppDelegate setWindow:] entry 24383 pid42589 dtracetest max entry 24384 pid42589 dtracetest myCFunc entry 24385 pid42589 dtracetest stub helpers entry
This brings up an interesting question. Does the automatic generation of these entry & return probes affect a running application in anyway? To be more specific, is code being inserted into the application or executed somewhere else to check, for example, if the myCFunc entry probe is enabled or not every time myCFunc is executed?
I would assume that the answer is NO to both questions. Extra code would only be inserted or executed if dtrace was told to enable the probe (by Instruments, for example). Is this correct?
~ $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.
The best guess right now is that this very strange error results from how the application was built. I was able to build it with the latest (released) version of Xcode under 10.6.3 and didn't get the error. The version generating the error was built using older (but not much older) software - the source is the same. I will probably be taking this particular issue to WWDC (and filing a bug report on it soon)...but it seems far less serious now.
|