fielding 98/10/09 14:22:27 Modified: . debugging.html Log: Add information about using truss Revision Changes Path 1.5 +31 -2 apache-devsite/debugging.html Index: debugging.html =================================================================== RCS file: /export/home/cvs/apache-devsite/debugging.html,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- debugging.html 1998/10/09 20:53:45 1.4 +++ debugging.html 1998/10/09 21:22:27 1.5 @@ -21,11 +21,13 @@
  1. Using 'gdb'
  2. Getting a live backtrace +
  3. Using 'truss/trace/strace' to + trace system calls and signals
-

Using 'gdb' +

Using 'gdb'

If you use the gcc or egcs compilers, it is likely that the best debugger for your system is gdb. This is only a brief summary of how @@ -162,7 +164,7 @@

-

Getting a live backtrace +

Getting a live backtrace

A backtrace will let you know the hierarchy of procedures that were called to get to a particular point in the process. On some platforms @@ -210,6 +212,33 @@ #4 0x449fc in main (argc=3, argv=0xefffeee4) at http_main.c:4534 (gdb) +

+ +

+ +

Using 'truss/trace/strace' to + trace system calls and signals

+ +

Most Unix-based systems have at least one command for displaying +a trace of system calls and signals as they are accessed by a running +process. This command is called truss on most SVR4-based +systems and either trace or strace on many +other systems. + +

A useful tip for using the truss command on Solaris is +the -f option; it tells truss to follow and continue tracing +any child processes forked by the main process. The easiest way to get +a full trace of a server is to do something like: +

  +    % truss -f httpd -d /usr/local/apache >& outfile
  +
+and let it run through a few requests before killing the parent. You can +then view the entire trace in outfile, or use something like +
  +    % egrep '^10698:' outfile
  +
+to view just the trace of the process id 10698. +