Stories
Slash Boxes
Comments
Search

News for nerds, stuff that matters

Slashdot Log In

Log In

[ Create a new account ]

Apple Crippled Its DTrace Port

Posted by kdawson on Tue Jan 22, 2008 06:26 PM
from the nothing-to-see-here dept.
Programming OS X Apple
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..."

Related Stories

Firehose:Apple crippled its DTrace port by Linnen (735667)
[+] Apple Quietly Fixes DTrace 131 comments
In January we discussed a blog entry revealing that Apple had "crippled" its DTrace port. As the author notes in a followup post, to say that DTrace had been "crippled" was at least overstated: "Unfortunately, most reactions seized on a headline paraphrasing a line of the post — albeit with the critical negation omitted." In an updated entry, the poster notes that Apple has made good (so we have too): "One issue was that timer based probes wouldn't fire if certain applications were actively executing (e.g. iTunes). This was evident both by counting periodic probe firings, and by the absence of certain applications when profiling. The good news is that Apple has (quietly) fixed the problem in Mac OS X 10.5.3."
This discussion has been archived. No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.

Apple Crippled Its DTrace Port 25 Comments More | Login /

 Full
 Abbreviated
 Hidden
More | Login
Loading... please wait.

  • And as quick as it is reported (Score:5, Informative)

    by Evets (629327) * on Tuesday January 22, @06:27PM (#22145352) Homepage Journal
    As quickly as the issue is reported, a hack [bikemonkey.org]comes out to resolve it. Gotta love how quickly the community can respond to these things.

  • Great! (Score:5, Insightful)

    by Jeremi (14640) on Tuesday January 22, @06:34PM (#22145444) Homepage
    So can I apply this NOATTACH flag to my l33t rootkit software to make sure it goes undetected by any system diagnostic tools?


    This will be a big help for me in my quest for a legion of Mac zombies ;^)

  • Luckily... (Score:5, Interesting)

    by cromar (1103585) on Tuesday January 22, @06:35PM (#22145476)
    From the DTrace source (in an #IFDEF APPLE):
    /*
    * If the thread on which this probe has fired belongs to a process marked P_LNOATTACH
    * then this enabling is not permitted to observe it. Move along, nothing to see here.
    */

    Luckily no malicious programmer will mark their malware's process with this flag!

  • Freedom Crippled when you use Proprietary Software (Score:5, Insightful)

    by Anonymous Coward on Tuesday January 22, @06:36PM (#22145482)
    You of all people should know that you give up your freedom to use your software and hardware as you wish when you use proprietary software. Apple's continuous attempt to stop people from changing software on their home computers is a good example of how they feel about freedom. They only side with freedom when it is immediately beneficial.
  • Is "egalitarian" the Slashdot word of the day today?
  • Fuck me, it's like a Student Union bar in here. What next, comrades, do we storm the Winter Palace or just go and sell some copies of Socialist Worker?
  • The article says, "To say that Apple has crippled DTrace on Mac OS X would be a bit alarmist..." So what is the Slashdot headline? "Apple Crippled Its DTrace Port"

    Nice...

  • It's worse, they have broken DTrace (Score:5, Informative)

    by mzs (595629) on Tuesday January 22, @06:50PM (#22145738)
    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.
  • The /. summary and most of the /. posters seem to be missing the point of the article. (To be fair, the author wasn't too clear himself. He's done some clarification in the comments section of his article.)

    Sure, it's annoying that DTrace can't "see" iTunes. But that's more of a DRM issue. Whether you agree with DRM and Apple's implementation of it or not, this DTrace feature is merely a logical extension of that issue.

    The real problem though is that this feature actually does break iTunes. If DTrace probes while the iTunes application happens to be the application currently running on the CPU, the DTrace probe won't run. (It's technically a thread of iTunes' at that moment.) So not only will DTrace not show iTunes, it won't show ANY information until it happens to fire off when iTunes isn't the app running on the CPU.

    It is fair to say that Apple has made a change to DTrace that has introduced a bug that they need to fix. It is possible for them to fix that bug while continuing to block using DTrace on iTunes.

  • So? (Score:5, Insightful)

    by Plekto (1018050) on Tuesday January 22, @07:23PM (#22146228)
    I just don't see what the big deal with all of this is. Smart people don't touch ITunes, because it's just going to help feed the beast. People seem to have forgotten how Jobs ran Apple the last time he was in charge. He's merely a lot more charismatic than Gates. But they are both equally self-serving.

    Thankfully there are options which involve neither company.

  • One step back (Score:5, Interesting)

    by bdgregg (744616) on Tuesday January 22, @07:40PM (#22146492) Homepage

    Yes, it's annoying - every time we examine the system we are now looking at everything except for iTunes (and possibly Spy-WaR3 ;-). But this issue is about more than just that.

    I've introduced DTrace to many companies. While most people love it, some developers of closed source software are concerned about people DTracing their code. DTrace allows customers to gather proof of bugs that are embarrassing, hard to fix, or that the developers have deny existed. I've been asked many times if DTrace can be disabled for an application, usually to avoid negative publicity from the bugs that DTrace will expose. The answer has always been no. It's been great to see developers accept this reality and escelate bug fixing.

    This is expected - DTrace visibility should improve overall code quality in IT. Hopefully it will also encourage employers to hire better programmers - since if customers don't use DTrace to point out embarassing bugs, then competitors may. It also erodes reasons to stay closed source - customers can use DTrace to see the code anyway.

    Giving developers another option, to disable DTrace visibility, is allowing a backwards step from the future.

  • What a tragedy (Score:5, Funny)

    by Slashcrap (869349) on Tuesday January 22, @08:06PM (#22146804)
    It's a real shame that you can't trace iTunes. I was all set to reverse engineer it and use the code to make my own total fucking abortion of a media player. Now I'll have to settle for grafting a horrible GUI onto Mplayer, removing most of the supported formats and making it sleep without releasing the CPU 90% of the time. If I can work out some way to reliably fuck up the contents of the user's iPod, then I doubt anyone will notice the difference.

    It will be tricky to make the Windows port twice as horrible though. Maybe I can get it to punch the user in the face every ten minutes?

    • Re:DRM? (Score:5, Insightful)

      by KublaiKhan (522918) on Tuesday January 22, @06:34PM (#22145460) Homepage Journal
      That may have been Apple's intent, but as usually happens in such cases, the end result is to encourage people to find out new ways around the 'protections' that have been inflicted.

      • Re:DRM? (Score:5, Insightful)

        by mstone (8523) on Tuesday January 22, @07:59PM (#22146734)
        Most likely, Apple's intent is to deliver a 'credible effort' to prevent circumvention and/or reverse engineering.

        Even though the labels have largely dropped DRM, they still don't like the idea of users having control over digital music. It's part of their DNA. Their whole business revolved around having control over the production and distribution systems, and they just can't contemplate existence without having control over something. The contracts between Apple and the labels reflect that fear, with Apple having the job of making it look like the horses are still in the barn even though the door is open.

        Now technically, that's impossible. But my experience with corporate software development has shown me that you can balance 'customers who don't want to know what's impossible' with judicious use of handwavium. You don't have to build a solution that's bulletproof, you just need something that works most of the time. It doesn't matter if there are workarounds, or even if those workarounds are practically trivial for anyone with a technical background, as long as you can't discuss the workaround without using technical terms.

        It's sort of an extension of the Sapir-Whorf hypothesis. It's not that your customers can't think about the problem if you lack the vocabulary, it's more that they won't want to think about the problem if they have to spend effort learning how to discuss it intelligently.

        So from a contractual standpoint, providing a 'credible effort' is more about obfuscation than actually trying to do the impossible. Apple probably doesn't care if people can work around this issue, as long as the explanation boils down to 'blah blah blah' to aggressively uninformed label executives.

    • Re:C'mon, seriously? (Score:5, Insightful)

      by bersl2 (689221) on Tuesday January 22, @06:58PM (#22145884) Journal
      (Note: IANA DTrace user or developer.)

      The real effects seem to be that while a process which sets this flag has control of the system, any DTrace events that fire off during this time will not be detected, as if they never occurred, regardless of whether what is being traced has anything to do with that process. It seems to break a few important(?) idioms used by DTrace users, so that the results returned are not what they should be.

      The furor seems to be that this subtle breakage has gone undocumented; and although only iTunes currently uses it, that does not stop other software (including software that should not be there) from using it. That a DTrace developer discovered this, combined with that this is in all likelihood being done for no reason other than that of DRM, is what makes this notable. If I were working on DTrace, I'd probably be pissed too.

All trademarks and copyrights on this page are owned by their respective owners. Comments are owned by the Poster. The Rest © 1997-2008 SourceForge, Inc.