fielding 98/10/09 15:14:05
Modified: . debugging.html
Log:
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>
</OL>
<HR>
-<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 @@
<HR>
-<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 @@
<HR>
-<H3><A NAME="truss"><B>Using '<CODE>truss/trace/strace</CODE>' to
- 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 @@
<HR>
-<P>Got more tips? Send 'em to <A
-HREF="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</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].
+<PRE>
+ # for pid in `ps -eaf | fgrep httpd | cut -d' ' -f4`
+ do
+ truss -f -l -t\!all -S SIGSEGV -p $pid 2>&1 | egrep SIGSEGV
&
+ done
+</PRE>
+
+<P>The <a href="http://www.dejanews.com/=zzz_maf/getdoc.xp?AN=352257973";>
+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:
+
+<PRE>
+ # gcore <i>PID</i>
+</PRE>
+
+and then look at the backtrace as discussed above for <a href="#gdb">gdb</a>.
+
+<P>
+
+<HR>
+
+<P>Got more tips? Send 'em to
+<A HREF="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]</A>. Thanks!
</BODY>
</HTML>
