Why iosnoop (IO snooping files on disk) returns paths with question marks?

Question

If I'm running

sudo iosnoop | grep "gem"

and then in another terminal run

gem env

in the iosnoop terminal I see:

dtrace: error on enabled probe ID 4 (ID 1106: io:mach_kernel:buf_strategy:start): illegal operation in action #3 at DIF offset 0
dtrace: error on enabled probe ID 4 (ID 1106: io:mach_kernel:buf_strategy:start): illegal operation in action #3 at DIF offset 0
dtrace: error on enabled probe ID 4 (ID 1106: io:mach_kernel:buf_strategy:start): illegal operation in action #3 at DIF offset 0
dtrace: error on enabled probe ID 4 (ID 1106: io:mach_kernel:buf_strategy:start): illegal operation in action #3 at DIF offset 0
dtrace: error on enabled probe ID 4 (ID 1106: io:mach_kernel:buf_strategy:start): illegal operation in action #3 at DIF offset 0
...
dtrace: error on enabled probe ID 4 (ID 1106: io:mach_kernel:buf_strategy:start): illegal operation in action #3 at DIF offset 0
  501 54406 R 21523616    512       bash ??/bin/gem
  501 94092 R 141320288   4096       bash ??/bin/gem
  501 94092 R 141320168   4096       ruby ??/1.8/rubygems.rb
  501 94092 R 141320208   4096       ruby ??/1.8/rubygems.rb
  501 94092 R 141319208   4096       ruby ??/rubygems/errors.rb
  501 94092 R 141319856   4096       ruby ??/rubygems/specification.rb
  501 94092 R 141319864   4096       ruby ??/rubygems/specification.rb
  501 94092 R 141319872   4096       ruby ??/rubygems/specification.rb
  501 94092 R 141319888   4096       ruby ??/rubygems/specification.rb
  501 94092 R 141319896   4096       ruby ??/rubygems/specification.rb
  501 94092 R 141319904   4096       ruby ??/rubygems/specification.rb
  501 94092 R 141319928   4096       ruby ??/rubygems/specification.rb
  501 94092 R 141319936   4096       ruby ??/rubygems/specification.rb
  501 94092 R 141319944   4096       ruby ??/rubygems/specification.rb
  501 94092 R 141320176   4096       ruby ??/1.8/rubygems.rb
  501 94092 R 141320184   4096       ruby ??/1.8/rubygems.rb
  ...

What are the question marks near ruby in the path to the files are treated:

ruby ??/1.8/rubygems.rb

? And how can I find the absolute path to all these files?

Additional question - why are the errors here:

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

?

Answer 1

The short answers are:

1. The ?? signify that the remaining pathname is unknown,
2. you can't extract the absolute path and
3. this is a feature, not a bug, of DTrace on OS X.

An explanation of these points requires some familiarity with DTrace; if appropriate then start with the introduction to the Solaris version.

iosnoop is a script that exploits the DTrace observability framework. In particular, it uses the io provider's start and done probes; the start probe exposes a request's bufinfo_t, the target device's devinfo_t and the corresponding file's fileinfo_t. The fileinfo_t is not a native Darwin type: it is a structure provided by dtrace(1) that provides a convenient abstraction of a file for the benefit of users. For example, amongst its members is fi_pathname, which should give the full pathname of a file.

Having an abstracted description shields users, and their scripts, from knowledge of and changes to the underlying implementation of the operating system. In theory, it also allows for a single script to run on different operating systems altogether.

A fileinfo_t is constructed and populated dynamically using a DTrace translator described in /usr/lib/dtrace/io.d. This shows the transformation from the OS-specific types to the abstraction. In the case of Snow Leopard I see that fi_pathname is constructed from the string "??/" followed by some derivates of the IO buffer. I'm no Darwin expert but I infer that it simply doesn't record full pathnames in its vnodes. This, hence, is the origin of the "??" in the output of your script and also the reason why I assume that the absolute pathnames are unavailable.

Finally, your DTrace errors. For whatever reasons, Apple's port of DTrace is subtly crippled in that it precludes tracing of various processes, and the error message that you see is a characteristic symptom. Specifically, the complaint is about the line

start_uid[this->dev, this->blk] = (int)uid;

and it turns out that (again, on Snow Leopard), trying to evaluate uid on any of the launchd, diskimages-help and kernel_task processes results in exactly this error. I presume that these processes are "out of bounds" and the errors that you see are the consequences of Apple's modifications.