httpd-cvs mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject cvs commit: apache-devsite debugging.html
Date Fri, 09 Oct 1998 22:14:06 GMT
fielding    98/10/09 15:14:05

  Modified:    .        debugging.html
  Add information on getting a core dump.
  Revision  Changes    Path
  1.6       +42 -6     apache-devsite/debugging.html
  Index: debugging.html
  RCS file: /export/home/cvs/apache-devsite/debugging.html,v
  retrieving revision 1.5
  retrieving revision 1.6
  diff -u -r1.5 -r1.6
  --- debugging.html	1998/10/09 21:22:27	1.5
  +++ debugging.html	1998/10/09 22:14:05	1.6
  @@ -23,11 +23,12 @@
   <LI><A HREF="#backtrace">Getting a live backtrace</A>
   <LI><A HREF="#truss">Using '<CODE>truss/trace/strace</CODE>' to
       trace system calls and signals</A>
  +<LI><A HREF="#gcore">Getting the server to dump core</A>
  -<H3><A NAME="gdb"><B>Using '<CODE>gdb</CODE>'</B></A></H3>
  +<H3><A NAME="gdb">Using '<CODE>gdb</CODE>'</A></H3>
   <P>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
  @@ -164,7 +165,7 @@
  -<H3><A NAME="backtrace"><B>Getting a live backtrace</B></A></H3>
  +<H3><A NAME="backtrace">Getting a live backtrace</A></H3>
   <P>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
  @@ -216,8 +217,8 @@
  -<H3><A NAME="truss"><B>Using '<CODE>truss/trace/strace</CODE>'
  -    trace system calls and signals</B></A></H3>
  +<H3><A NAME="truss">Using '<CODE>truss/trace/strace</CODE>' to
  +    trace system calls and signals</A></H3>
   <P>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
  @@ -242,8 +243,43 @@
  -<P>Got more tips?  Send 'em to <A
  -HREF=""></A>.  Thanks!
  +<H3><A NAME="gcore">Getting the server to dump core</A></H3>
  +<P>Strangely enough, sometimes you actually want to force the server
  +to crash so that you can get a look at some nutty behavior.  Normally
  +this can be done simply by using the <CODE>gcore</CODE> command.
  +However, for security reasons, most Unix systems do not allow a setuid
  +process to dump core, since the file contents might reveal something
  +that is supposed to be protected in memory.
  +<P>Here is one way to get a core file from a setuid Apache httpd process
  +on Solaris, without knowing which httpd child might be the one to die
  +[note: it is probably easier to use the MaxClients trick in the first
  +section above].
  +    # for pid in `ps -eaf | fgrep httpd | cut -d' ' -f4`
  +    do
  +      truss -f -l -t\!all -S SIGSEGV -p $pid 2&gt;&amp;1 | egrep SIGSEGV &amp;
  +    done
  +<P>The <a href="">
  +undocumented '-S' flag</a> to truss will halt the process in place
  +upon receipt of a given signal (SIGSEGV in this case).  
  +At this point you can use:
  +    # gcore <i>PID</i>
  +and then look at the backtrace as discussed above for <a href="#gdb">gdb</a>.
  +<P>Got more tips?  Send 'em to
  +<A HREF=""></A>.  Thanks!

View raw message