Apple Crippled Its DTrace Port
Linnen writes in to note that one of developers of Sun's open source system tracing tool, DTrace, has discovered that Apple crippled its port of the tool so that software like iTunes could not be traced. From Adam Leventhal's blog: "I let it run for a while, made iTunes do some work, and the result when I stopped the script? Nothing. The expensive DTrace invocation clearly caused iTunes to do a lot more work, but DTrace was giving me no output. Which started me thinking... did they? Surely not. They wouldn't disable DTrace for certain applications. But that's exactly what Apple's done with their DTrace implementation. The notion of true systemic tracing was a bit too egalitarian for their classist sensibilities..."
As quickly as the issue is reported, a hack comes out to resolve it. Gotta love how quickly the community can respond to these things.
Basically profile and tick are useless since they will not fire if a thread with PT_DENY_ATTACH is on proc. Perfectly good DTrace scripts simply will not work correctly on OS X.
It's nice that Dtrace works again. But I'm betting a lot more people use After Effects or Premiere. The QT 7.4 update which enables movie rentals from iTunes breaks any render that takes longer than 10 minutes. Thank god DRM is here to protect me from the work I need to do. Wasn't apple supposed to me the machine for media professionals?
http://blogs.adobe.com/keyframes/2008/01/dont_update_to_quicktime_74.html
Actually, Leopard's DTrace is broken, and that was the point of the blog post. Here's the issue: DTrace programs that would normally work and collect valid data will fail if a process is running with Apple's trace-me-not bit set. Forget tracing iTunes or other applications that don't want to be traced. It's that probes that should fire don't as an unintended side-effect of Apple's hack to obscure certain applications.
A much smarter approach would have been for Apple to deny visibility into such a process, but still allow a user to monitor system-level events (e.g. timers and system calls). This would have allowed for the (questionably motivated, and highly circumventable) protection while not damaging DTrace and correctly phrased queries.
Maybe everyone knows what dtrace is. I didn't. Then I watched this: link and now I do.
http://ed.markovich.googlepages.com
Back in 2000, if you installed MacsBug on a Mac you couldn't play DVDs. When you opened the DVD Player you got an error message telling you a debugger was installed. In these pre-memory protection days, MacsBug was the only debugger low-level enough to catch a whole mess of problems. Unfortunately, MacsBug was loaded when the system booted, so the only way to play a DVD was to remove MacsBug and restart your machine.
Long time Mac developer ally Bare Bones Software (they have a great text editor) created a patch that "fixed" this limitation. AFAIK, Apple never said anything about their patch and just quietly let it exist. http://www.macobserver.com/news/00/april/000418/dvdplayerhelper.shtml
This whole message mess came about because Macrovision didn't want people disabling their protection on video-output (there were Macs you could literally plug into VCRs then), and I suspect it was also to guard the CSS "encryption."
When Blu-ray movies finally show up in Macs, this kind of thing is probably going to get a lot worse than patches to D-Trace.