Differences

This shows you the differences between two versions of the page.

--- apache:troubleshooting:determine_why_an_apache_process_hung [2021/02/02 11:00] – created peter
+++ apache:troubleshooting:determine_why_an_apache_process_hung [2021/02/02 11:05] (current) – [Use gdb utility to retrieve a stack backtrace from the core file] peter
@@ Line 3: / Line 3: @@
 Sometimes a web server will just hang, or hard crash, or return malformed content.
-Finding the reason the server hung typically requires reviewing each stack frame that led to the current frame, and selectively dumping server data structures.
+Finding the reason for this typically requires reviewing each stack frame that led to the current frame, and selectively dumping server data structures.
 Debugging in this manner takes time, and may not be appropriate for sites that require constant availability.
@@ Line 19: / Line 19: @@
 There are several tools that can be used to get a stack backtrace, including:
-  * **pstack**:
+  * **pstack**:  attaches to the active processes named by the pids on the command line, and prints out an execution stack trace, including a hint at what the function arguments are.
   * **gcore**:  generate a core file from a hung web server process.
-  * **gdb**:
+  * **gdb**:  the GNU Project debugger, allows you to see what is going on 'inside' another program while it executes.
+The results from these methods could be fed into the Apache bug database to see if the problem is caused by a well known issue.
-If a problem was present in the server, these methods could be fed into the Apache bug database to see if the problem is caused by a well known issue.
 </WRAP>
@@ Line 54: / Line 53: @@
   * **accept**:  Apache was in the **accept()** system call when the error was received.
-Some systems do not have the **pstack** utility.
+Some systems do not have the **pstack** utility.  In these cases try using the **gdb** and **gcore** utilities to get a stack backtrace from a process.
-  * In these cases try using the **gdb** and **gcore** utilities to get a stack backtrace from a process.
 </WRAP>
@@ Line 91: / Line 88: @@
 **NOTE:**  This shows:
-  * **accept ()**:  Apache was in the accept() system call when a SIGSEGV signal was received, and accept() was called by the portable runtime method **apr_socket_accept()**.
+  * **accept ()**:  Apache was in the **accept()** system call when the SIGSEGV signal was received.
-  * **accept ()**:  Apache was in the **accept()** system call when the error was received.
     * **accept()** was called by the portable runtime method **apr_socket_accept()**.
 </WRAP>
@@ Line 102: / Line 97: @@
 <code bash>
-gcore 5649
+gcore 4932
 </code>
@@ Line 132: / Line 127: @@
 **NOTE:**  This shows:
-  * **accept ()**:  Apache was in the accept() system call when a SIGSEGV signal was received, and accept() was called by the portable runtime method **apr_socket_accept()**.
+  * **accept ()**:  Apache was in the **accept()** system call when the SIGSEGV signal was received.
-  * **accept ()**:  Apache was in the **accept()** system call when the error was received.
     * **accept()** was called by the portable runtime method **apr_socket_accept()**.
 </WRAP>