When running iotop -C 5 12 on my late-2010 Macbook Pro (10.6.7) I get repeated instances of this error:

dtrace: error on enabled probe ID 5 (ID 19507: io:mach_kernel:buf_strategy:start): illegal operation in action #3 at DIF offset 0

What's the cause of this and how do I fix it?

4 Answers 4


According to this blog post (with more information here), it's caused by iTunes, which DTrace "filters" so it can't be used to try to break iTunes' DRM.

Quitting iTunes resolves the error.

  • 15
    I get this error even when iTunes isn't running.
    – studgeek
    Nov 25, 2012 at 14:52

The errors are getting output to stderr, and can be filtered out by running the command as such:

sudo iotop -C 5 12 2>/dev/null

This does have the side effect of filtering out any other errors that might come up. I've found it to be an ok tradeoff, in that it's made my iotop output readable.

I'm not sure what the cause of the errors are, unfortunately. I've searched, but have not been able to find anything as of yet.

  • 1
    That's just sweeping the errors under the carpet and pretending they don't exist! The question was asking what caused them and how to fix them, not "how do I ignore them?".
    – markshep
    Sep 4, 2017 at 10:52

In short, the error is shown when attempting to trace a process that has requested not to be traced.

The error isn't technically cause by iTunes, but by a process that has disabled tracing, using code like the following.

ptrace(PT_DENY_ATTACH, 0, 0, 0);

This code sets a flag on the process on the kernel level, which prevents debugging and tracing of the process.

The best-known application that does this just happens to be iTunes, the application whose DRM this API was probably invented for, but the API is available to other processes. I have seen a number of 3rd party application use this API.

Of course, like all DRM it can be broken. Options for bypassing this anti-tracing and anti-debugging feature range from using a debugger to skip the API call to kernel extensions that patch the feature out in kernel space.


Taken from https://unix.stackexchange.com/a/276219

This is potentially related to El Capitan and its System Integrity Protection (csrutil status) which can affect the dtrace behaviour.

The potential fix includes rebooting Mac into recovery mode (-R at boot time), then in Terminal run:

csrutil enable --without dtrace

to keep SIP enabled, but disable DTrace restrictions (note: this is undocumented parameter).

Or disable SIP completely by:

csrutil disable # Not recommended.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.