Apple Quietly Fixes DTrace

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."

Comments

Took them long enough

[cibyr]

These sort of concurrency issues are bad enough when they're bug in your *own* code. When it's stuff in other apps producing what appears to be strange behaviour in your own (perfectly fine) code, that's a BIG problem.

This sort of issue wouldn't survive for a week on Linux.

Re:Took them long enough

[morgan_greywolf]

While it might have seemed to some that tinfoil hats were in order (and maybe some might think they still are), it seems to me that this was likely just a bug in Apple's port of DTrace. Does anyone know if they posted (or will post) any patches for DTrace upstream?

Re:Took them long enough

[powerlord]

This sort of issue wouldn't survive for a week on Linux.

Developer specific issues like this would certainly be fixed quickly under Linux, since it is a developer OS. On the other hand, usability issues that get fixed quickly under OS X, are often left to languor under Linux.

In both cases those features may never be fixed under Windows (or would be broken again after the next "Service Pack" :P )

Re:Took them long enough

[Anonymous Coward]

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 so they added this glob of lard into dtrace_probe() -- the heart of DTrace:

#if defined(__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.
*/
if (ISSET(current_proc()->p_lflag, P_LNOATTACH)) {
continue;
}
#endif /* __APPLE__ */

Re:Took them long enough

[jonwil]

Its clear from the DTrace source from Apple that this is intentional. The OS has a "this app cannot be debugged" flag and they deliberatly made the decision that "cannot be debugged" == "cannot be DTraced"
Most likely they are trying to prevent tracing/debugging/reverse engineering of apps like iTunes and QuickTime that host ITMS DRM content.

Re:Took them long enough

[Lally Singh]

It was apple-specific. They had a "don't debug me" flag that a process could set at startup (to protect DRM). But there was a bug in the interaction of these processes that could cause dtraced processes to take *forever*.

Re:Took them long enough

[Ephemeriis]

These sort of concurrency issues are bad enough when they're bug in your *own* code. When it's stuff in other apps producing what appears to be strange behaviour in your own (perfectly fine) code, that's a BIG problem.

This sort of issue wouldn't survive for a week on Linux. If you read the original story, which this one is an update to, then you'll see that there are no bugs - only features.

Apple intentionally disabled DTrace on some software.

You can actually take a look at Apple's DTrace source.

Re:Took them long enough

[Anonymous Coward]

Surely you could just recompile dtrace for mac os x without the check though?

Re:Took them long enough

[somersault]

Obviously DRM crackers are incapable of this level of ingenuity (if you live in cuckoo land that is..)

Re:Took them long enough

[Crazyswedishguy]

Their passive-aggressive relationship with multiple mouse buttons is a crying shame. To be honest, to me this seems like a thing of the past. Apple-critics tend to use it as an argument against Macs but really, that was fixed when the Mighty Mouse came out. I would argue even before that, since I was using out-of-the-box (as in drivers already installed) a Microsoft 5-button mouse on my first Powerbook, and could configure all the buttons. If you're working on a Macbook or Macbook pro, I find the "double-finger click" (whatever you want to call it) equally if not more convenient than having a right-click button.

I know Macs aren't perfect, and there are other issues with them, but is the "passive-aggressive relationship with multiple mouse buttons" really still a reality?

(Obligatory disclaimer: I am, admittedly, somewhat of an Apple fanboi, but I do agree that Macs have their flaws as well. I just tend to prefer Apple products for design and usability - they fit my needs. I made the switch about 5 years ago)

Re:Took them long enough

[99BottlesOfBeerInMyF]

Their passive-aggressive relationship with multiple mouse buttons is a crying shame.

I find their stance on mouse buttons to be ideal. As a usability expert, I can assure you misuse of secondary mouse buttons is one of the most common usability problems, even for more advanced users, although they often do not consciously note it. For novice users, a single mouse button is by far preferable. For trackpad users, both novice users and power users complete tasks faster using two-finger taps or chording... with only midrange users having issues. Standardizing one one button as the requirement for developers to target also improves overall usability. It means if you are using an alternate input method like a stylus, voice interface, handicap interface, or if you are scripting actions within an application, all functions are accessible in the same, standard way, with no functionality exclusively available to users that can easily access a second mouse button. This also means the second mouse button functionality can be customized by the user, since it is not required to operate any application. That means in my text editor on OS X I don't have useless option in the context menu brought up by the second button (as is the case in Wordpad in WinXP). Instead I assign useful items to that context menu, like a service for auto-replacing line endings. Basically, I think you're way off when it comes to the multi-button mouse thing. The "might mouse" is an ideal new mouse for home computers with multiple users as it is the first I know of that lets software decide if the mouse is multi-button or single button based upon the user account. Apple has its share of usability problems, but their practices with regard to mouse buttons are not one of them. Mostly it is just Windows users complaining because it is different or people who don't actually use OS X regularly complaining about what they assume would be a problem.

Re:Took them long enough

[argent]

As a usability expert, I can assure you misuse of secondary mouse buttons is one of the most common usability problems,

Argumentum ad verecundiam. I've been seeing people make claims like this for almost 25 years now, and I have yet to see a single credible study that supports it.

Single button mice are more "demo friendly". That's it.

* Applications are *not* as consistent as you claim. There are many actions even in Apple's apps that are only available through the contextual menu, or through magic chords.

* These magic chords, the alternate mechanisms for replacing the context menu in Mac OS, are not "discoverable". I've been using the Mac almost as long as it's been out... my first Mac was the original 128K Macintosh, I'm definitely a "power user", and I'm still discovering new command-option-shift-double-click combos.

* Using contextual menus does not prevent user configuration.

Mostly it is just Windows users complaining because it is different or people who don't actually use OS X regularly complaining about what they assume would be a problem.

Argumentum ad hominem, too. Not guilty. I use OS X regularly, I've used Macs for almost a quarter of a century. OS X is my primary desktop.

Re:Took them long enough

[NMerriam]

Argumentum ad verecundiam. I've been seeing people make claims like this for almost 25 years now, and I have yet to see a single credible study that supports it.

Anyone who has spent a day answering phones on a tech support line can confirm that mixing up mouse buttons is a common issue.

"right click on the icon"
"double click?"
"no, ma'am, click the right button on your mouse"
"how do I know which button is the right one?"

Re:Took them long enough

[somersault]

Fair enough, though 'usability' generally refers to interface design, I'd definitely still refer to it as a security issue, which I'd say is more important than 'usability', though successful software companies like MS and Apple don't seem to agree!

Re:Took them long enough

[LordGilman]

You don't even have to recompile dtrace, there's a kernel extension that patches around Apple's code. http://landonf.bikemonkey.org/code/macosx/Leopard_PT_DENY_ATTACH.20080122.html

Good news

[Anonymous Coward]

This was blogged about some days ago, but I'm glad that the news is out.

DTrace is used in all sorts of interesting ways. On the Belenix project, for e.g., we've sped up the LiveCD boot enormously, and this innovative use of DTrace is now part of the Distro Constructor Toolkit at opensolaris.org.

On my Dell D620, Belenix boots in about 3 and a half minutes (with KDE), while Ubuntu 7.10 boots up in about 8 minutes.

-- Sriram
http://www.belenix.org/
http://dynamicproxy.livejournal.com/

Re:Good news

[Anonymous Coward]

That's just sad. You shouldn't flash those numbers in public.

Good going apple!

[YeeHaW_Jelte]

Your evilness index has just dropped from 45.8 to 45.3

Keep up the good work!

Quietly, quietly

[gonerill]

What is the connotation of "quietly" supposed to be in stories like this? (Not just with Apple.) It seems like a weasel word. Is the intention to give the impression that Apple embarrassedly corrected themselves, or that they were forced to give into pressure from the developer community, but don't have the cojones to admit it, or what? Because, anyone honestly expecting something other than a "quiet" fix is deluded. Is a bug fix in DTrace supposed to get a slide at a Stevenote or something?

Re:Quietly, quietly

[stewbacca]

"Quietly" infers that the slashdot crowd should get credit, where no credit is due, as if our overwhelming numbers and sheer pressure forced Apple to change. Unfortunately, in the real world, we are such an insignificant demographic, that any changes are thus labelled as being done "quietly".

Re:Quietly, quietly

[timeOday]

Looking at the blog entry, no mention is made of an apple announcement at all; this blogger infers it is fixed based on what he would expect to see. What better definition of "quietly fixed" do you want?

From a developer standpoint, this is a very bad thing apple did. Understanding what's going on and getting stuff to work is hard enough without zombified debugging tools that lie to you.

"Quietly"

[Plantain]

What did you want, a friggin' parade?

Jeez, give a fruit a break.

Re:Mac's Suck

[antifoidulus]

Don't use xcode?

Seriously, unless you are developing Cocoa(or Carbon) apps, there is very little reason to use XCode. There are better free software programs out there for writing c++ code, not to mention you could always just call good ol' gcc on the command line....

Re:Mac's Suck

[Plantain]

Lifted from http://developer.apple.com/qa/qa2001/qa1118.html because I know no one will RTFA

Q: I'm trying to link my binary statically, but it's failing to link because it can't find 'crt0.o.' Why?

A: Static linking of user binaries is not supported on Mac OS X. Tying user binaries to the internal implementation of Mac OS X libraries and interfaces would limit our ability to update and enhance Mac OS X. Instead, dynamic linking is supported (linking against crt1.o automatically instead of looking for crt0.o, for example).

We strongly recommend that you consider the limitations of statically linking very carefully, and consider your customer and their needs, plus the long-term support you will need to provide. Apple provides support and attempts to insure complete compatibility through the published APIs, but cannot insure that compatibility in a statically linked project. Any change to Mac OS X, in a system update, security update, or major revision, may break statically linked code.

If your project absolutely must link statically and need crt0.o, you can get the Csu module from Darwin and try building crt0.o statically. Please bear in mind that you must then clearly specify to your customers the compatibility risks involved in installing a product that relies on statically linked code.

Re:Mac's Suck

[Halo1]

Write a simple c or c++ hello_word program. Then try to compile and link it with Xcode using -static. It won't work b/c Apple has fucked-up ld. It has nothing to do with ld. The reason it doesn't work is that there is no static version of libc (aka libSystem) on Mac OS X. And the reason for that is that on Mac OS X, libc is the lowest level publicly supported system interface.

There are of course system calls (both BSD-style and Mach-style ones), but they are undocumented and can change from one Mac OS X version to another (even between minor system updates). The reason is that Apple wants to have and keep full freedom in changing the systemuser space interface at any time it wants whenever that's convenient for whatever reason (performance, security, getting rid of legacy cruft, ...).

So if you'd statically link a program, it would be linked to a particular libc version which in turn would use the system calls as they work on the particular version of Mac OS X this libc version was compiled for. The end result would be that your program would only be guaranteed to function correctly on that particular OS revision.

libc's interface on the other hand is kept backwards compatible between OS revisions, so as long as you dynamically link against it, your program will work fine on pretty much any OS version out there (except if you use APIs which didn't exist yet in older versions).

This is more or less the opposite case as on e.g. Linux, where glibc breaks binary compatibility every other full moon (so you need to distribute different binaries for different glibc versions if you want to link dynamically to it), but the kernel's system call interface is pretty much guaranteed to remain backwards compatible for a very long time (so statically linked binaries are generally much more portable across distributions â" the downside is that you then should link everything statically because installed dynamic libraries may rely on features provided by a newer glibc than the one you statically linked, and in case of e.g. a KDE or GNOME app you'd end up with immense binaries).

DTrace 2.0: Now 30% Less Crippled!

[NoCowardsHere]

Apple designed their port of DTrace so that any program could "opt-out" of profiling if the developers are concerned about reverse-engineering. An unintended consequence of this was that it sometimes broke profiling of other apps while those apps were running. They've fixed that bug in their implementation of crippling, but that doesn't mean they've un-crippled it.

It's a big step forward, because now at least developers can properly profile their own code. However, one of the purposes of DTrace is to profile _anybody's_ code, in order for example to diagnose performance problems on your computer perhaps caused by those programs. Apple has intentionally left that feature out. So it's arguably still pretty crippled.

Re:Mac's Suck

[mwlewis]

You must be joking. Have you ever written a project that had more than 5 C++ files? I work on projects that have dozens -- if not hundreds -- of different files, organized into multiple different directories, with many different library dependencies and different configuration options. Manually calling gcc is simply impossible, unless I want to waste half a day every time I need to compile something.

WTF? It's called a makefile. "Manually invoking" gcc goes something like this:

$ make

Good news doesn't sell

[snowwrestler]

The previous discussion generated hundreds of posts within a few hours, and topped out at 476. This one is at 60 comments after 3 hours and will be lucky to break 100. If you've ever wondered why Slashdot posts flamebait stories, there's your answer. "If it bleeds it leads."