Discussion Over Apple's Modification Of Sun's DTrace

One of the most anticipated features of Mac OS X Leopard amongst the technical community was the port of Sun's DTrace utility for application and system profiling. DTrace is a powerful, low-level dynamic tracing framework that allows system administrators and developers to trace applications for tuning or troubleshooting purposes.

Recently, Adam Leventhal, one of DTrace's initial developers, discovered that Apple's implementation creates a way for a program to exclude itself from being traced. Namely, he was unsuccessful at tracing iTunes, and found that Apple had added a method of disabling probing on certain applications defined with the directive P_LNOATTACH.

Wow. So Apple is explicitly preventing DTrace from examining or recording data for processes which don't permit tracing. This is antithetical to the notion of systemic tracing, antithetical to the goals of DTrace, and antithetical to the spirit of open source. I'm sure this was inserted under pressure from ISVs, but that makes the pill no easier to swallow.

Since the initial publication of the blog entry last week, the story has begun to pop up around the mac web.

The practice is not entirely new to Apple. A commenter on Adam Leventhal's blog noted that Apple used the same directive to prevent GDB tracing on iTunes. Additionally, the implementation of this directive appears to be limited to iTunes (for the moment?), so many are speculating that the move is to protect Apple's FairPlay DRM.

To present an alternate view, Apple has extended Java, Ruby, Python, and Perl to include DTrace support, and Apple has built a GUI front-end called Instruments. Also the issue may eventually become moot with Apple's stated desire to move towards DRM-free music (though DRM video remains common).