Technical Q&A QA1573

Debugging Process Startup

Q:  How do I debug a process's startup code?

A: This depends on how the process is launched. For a typical application-level process, you can debug the startup code by launching it from within the debugger in Xcode. However, there may be circumstances where that's not an option. For example:

The following sections describe various ways to debug a process's startup code.

Write Code To Stop

If you can build the program from source, it's trivial to add code to stop the program at the first line of main. Listing 1 shows an example of this.

Listing 1  Code to stop at startup

#include <signal.h> #include <unistd.h> int main(int argc, char **argv) {     (void) raise(SIGSTOP);     /// rest of your code here }

This sends a SIGSTOP to the process, which stops its execution so that you can attach using GDB. Alternatively, you can resume execution by sending the process a SIGCONT using kill.

launchd

If it's not convenient to build the program from source, you can use a variety of other techniques. If your program is managed by launchd, you can add the WaitForDebugger property to your property list file to have launchd stop your program before it it executes a single instruction. See the man page for details.

GDB

If your program is not managed by launchd, you can use GDB's --waitfor option. GDB will poll the process list waiting for a matching process to be launched. You can supply the option either on the command line or as an argument to GDB's attach command.

The fact that GDB polls the process list has two drawbacks. Firstly, it consumes a lot of CPU while waiting for the process to be launched. Secondly, the program stops in an indeterminate state. If you're running on Mac OS X 10.5 or later, it's probably better to use DTrace instead.

DTrace

Listing 2 shows an example DTrace script that sets a probe on a commonly used system call (getpid) and, when that probe is hit, stops the process and invokes GDB on it. Listing 3 shows an example of its use.

Listing 2  WaitAttach.d

#! /usr/sbin/dtrace -w -q -s

syscall::getpid:entry
/ execname == $$1 /
{
    stop();
    system(
        "echo attach %d > /tmp/WaitAttach.gdb ; gdb -x /tmp/WaitAttach.gdb", 
        pid
    );
    exit(0);
}

Listing 3  Using WaitAttach.d

$ # Make the script executable
$ chmod ugo+x WaitAttach.d
$ # Run it
$ sudo ./WaitAttach.d TextEdit
GNU gdb 6.3.50-20050815 [...]
[... now launch TextEdit ...]
Attaching to process 3723.
Reading symbols for shared libraries . done
0x8fe21a25 in __dyld_getpid ()
(gdb) bt
#0  0x8fe21a25 in __dyld_getpid ()
#1  0x8fe07139 in __dyld__ZN4dyld5_mainEPK11mach_headermiPPKcS5_S5_ ()
#2  0x8fe01872 in __dyld__ZN13dyldbootstrap5startEPK11mach_headeriPPKcl ()
#3  0x8fe01037 in __dyld__dyld_start ()

You can modify this script to meet your particular needs. For example:



Document Revision History


DateNotes
2007-12-21

New document that describes techniques for debugging a process's startup code.