Monitor Cocoa apps for execution of external utilities (e.g., ffmpeg) on Mac OS X? - cocoa

Question

There are Mac GUI applications which provide a front-end to more geeky commandline tools (often included as a part of the application package). I would like to look at what is happening under the hood of such GUIs.
How to "attach" to an application, monitor it for calls to command line utilities and log a filename and command line parameters of these calls?
A solution can also be an application that logs execution of all applications on Mac OS X (filtering out the most common system calls).
Example GUI frontend: http://xact.sourceforge.net/ (since it is open source one can just debug it, but xACT is just an example. let's pretend we have just a ready-made *.app to monitor).
Update: dtrace can monitor exec calls and print name of the command called. that's a half of the solution, the other half is getting its command line arguments. that's unsolved yet (until someone confirms they have got dtrace to do this).

Answer 1

DTrace can do the job. Based on the discussion I had with Joey Hagedorn in the comments elsewhere on this question, the script that comes with 10.6 can be improved to work with a reasonable number of arguments (50+). Because the script has a lot of repetition, I'll include here a script which outputs the DTrace script which works well. This one does up to 50 arguments; you may want to extend the number of arguments by changing the for-loop.
#!/bin/bash
cat <<HEADER
#!/usr/sbin/dtrace -s
/*
* newproc.d - snoop new processes as they are executed. DTrace OneLiner.
*
* This is a DTrace OneLiner from the DTraceToolkit.
*
* 15-May-2005 Brendan Gregg Created this.
*/
/*
* Updated to capture arguments in OS X. Unfortunately this isn't straight forward...
*/
#pragma D option quiet
this unsigned long long argv_ptr; /* Wide enough for 64 bit user procs */
proc:::exec-success
{
print_pid[pid] = 1; /* This pid emerged from an exec, make a note of that. */
}
/*
* The "this" variables are local to (all) of the following syscall::mmap:return probes,
* and only those probes. They must be initialized before use in each new firing.
*/
syscall::mmap:return
{
this->argc = 0; /* Disable argument collection until we notice an exec-success */
}
syscall::mmap:return
/ print_pid[pid] /
{
print_pid[pid] = 0;
this->is64Bit = curpsinfo->pr_dmodel == PR_MODEL_ILP32 ? 0 : 1;
this->wordsize = this->is64Bit ? 8 : 4;
this->argc = curpsinfo->pr_argc;
this->argc = (this->argc < 0) ? 0 : this->argc; /* Safety */
this->argv_ptr = curpsinfo->pr_argv;
printf("%d %s ", pid, this->is64Bit ? "64b" : "32b");
}
HEADER
for ((i=0;i<50;++i)); do
cat <<REPEAT
syscall::mmap:return
/ this->argc /
{
this->here_argv = copyin(this->argv_ptr, this->wordsize);
this->arg = this->is64Bit ? *(unsigned long long*)(this->here_argv) : *(unsigned long*)(this->here_argv);
printf("%s ", copyinstr(this->arg));
this->argv_ptr += this->wordsize;
this->argc--;
}
REPEAT
done
cat <<FOOTER
syscall::mmap:return
/ this->argv_ptr /
{
printf("%s\n", this->argc > 0 ? "(...)" : "");
this->argc = 0;
this->argv_ptr = 0;
}
FOOTER

Answer 2

newproc.d is yet another dtrace script which does also output the command line arguments of the processes in the to the process names. Running it is simple:
sudo newproc.d
This works for me on OS X Mountain Lion. Older versions may have various problems; see the comments thread on this ServerFault answer for some discussion of newproc.d on Leopard and Snow Leopard.
Also, you should be aware of a few minor limitations. If you take a look at the script's source code, it indicates that it will not display more than 5 arguments, and it will not display arguments that are longer than 128 characters in length:
/*
* Updated to capture arguments in OS X. Unfortunately this isn't straight forward... nor inexpensive ...
* Bound the size of copyinstr()'s and printf incrementally to prevent "out of scratch space errors"
* print "(...)" if the length of an argument exceeds COPYINSTRLIMIT.
* print "<...>" if argc exceeds 5.
*/
inline int COPYINSTRLIMIT = 128;

Answer 3

You could use dtrace to monitor the exec*() system calls and display the arguments when they're invoked. dtrace is documented here:
https://wikis.oracle.com/display/DTrace/Documentation

Answer 4

Graham: dtrace would be perfect here. could you (or anyone else here) show a dtrace script that would print the commandline of the process?
This oneliner prints names of processes being executed:
dtrace -qn 'syscall::exec*:return { printf("%Y %s\n",walltimestamp,curpsinfo->pr_psargs); }'
But how to get / print their command line arguments?