One of the three authors of Sun's DTrace, Adam Leventhal, has discovered something very interesting using DTrace on Mac OS X. "As has been thoroughly recorded, Apple has included DTrace in Mac OS X. I've been using it as often as I have the opportunity, and it's a joy to be able to use the fruits of our labor on another operating system. But I hit a rather surprising case recently which led me to discover a serious problem with Apple's implementation." So, what is this problem? "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. To say that Apple has crippled DTrace on Mac OS X would be a bit alarmist, but they've certainly undermined its efficacy and, in doing do, unintentionally damaged some of its most basic functionality. To users of Mac OS X and of DTrace: Apple has done a service by porting DTrace, but let's convince them to go one step further and port it properly."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-06-29
By the way, what's the point of dtracing iTunes or WMP? Give me some valid reason. It's not "user-serviceable".
And you're free to debug your own app to your heart's content.
After all, if you want control, you can have Linux. Why should Apple give access to parts of the system that they don't want to?
Member since:2005-06-29
Also in reply to Thomas' comment above.
And you're free to debug your own app to your heart's content.
Err, do you know the intricacy of a modern computer system? Let me repeat my previous comment: "Well, the part that you can't monitor could be exactly that part that influences or affects the thing you are trying to monitor or debug. The purpose of a system-wide tracer is that it traces... System-wide. If something is wrong with your car, but you have no idea what it is, you'd like it if the garage had the ability to check every possibility, right?"
I hate repeating myself over and over again, but it is not at all hard to imagine how issues with iTunes could (negatively) affect the performance of your application, and now, you cannot find that out properly using DTrace - and who knows what other apps or parts of OSX are excluded from DTrace?
So, again, what good is a system-wide tracer, which programmers expect to analyse all possible influences on their code, if it does not trace system-wide? And, you do not know what gets and what does not get traced?
I'm not even a programmer, and even I can see how this literally cripples the usefulness of DTrace on OSX.
Edited 2008-01-20 16:23 UTC
Member since:2005-11-11
By the way, what's the point of dtracing iTunes or WMP?
Whether or not I can think of one now, it's impossible to say there won't be such a reason at some point down the road. Echoing Thom, what part of System Wide don't you get?
The interactions between software can be weird. The other week I was called in to look at someone's iMac that was misbehaving. They couldn't open the control panel: every time they did it immediately crashed. Not being a Mac guy I did my best to follow the trail, and eventually found that removing a recently installed DivX plugin fixed things.
It was preventing anything with sound from working. Pressing tab on the terminal crashed the terminal. Pressing the volume keys on the keyboard crashed the desktop. Safari crashed when playing any flash. And somehow sound being borked was causing Control Panel to crash on launch.
Why on earth would a DivX codec, player and converter package crash any sound app, and why would sound being broken prevent Control Panel from working? I have no idea.
The point is, software can interact in unexpected ways, and when things are well integrated into the OS like Quicktime or iTunes it might be necessary for someone to include them in their system wide debugging efforts.
It's easy for you to challenge someone to come up with an instance of when it might be necessary, but that's not the same thing as proving that such a thing will never be necessary, it's just showing that it isn't necessary right now for anyone who might be bothered to reply.
*edit* spelling
Edited 2008-01-20 16:36 UTC
Member since:
2005-06-29
Well, the part that you can't monitor could be exactly that part that influences or affects the thing you are trying to monitor or debug. The purpose of a system-wide tracer is that it traces... System-wide. If something is wrong with your car, but you have no idea what it is, you'd like it if the garage had the ability to check every possibility, right?