Apache core dump + backtrace

gistfile1.txt

The following example shows how to use the gcore utility to force a hung process to dump core, and then shows how the gdb utility can be used to retrieve a stack backtrace from the core file:

$ gcore 5649

$ gdb -q /usr/sbin/httpd core.5649

(gdb) backtrace
#0  0x0046e7a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x0063b681 in accept () from /lib/tls/libpthread.so.0
#2  0x00b14814 in apr_socket_accept (new=0xbff85740, sock=0x9671538, 
    connection_context=0x97115d8) at network_io/unix/sockets.c:187
#3  0x080819ce in unixd_accept (accepted=0xbff85774, lr=0x9671518, ptrans=0x97115d8) at unixd.c:466
#4  0x0807fd2e in child_main (child_num_arg=Variable "child_num_arg" is not available.) at prefork.c:621
#5  0x0807ffc2 in make_child (s=Variable "s" is not available.) at prefork.c:736
#6  0x08080050 in startup_children (number_to_start=5) at prefork.c:754
#7  0x0808089b in ap_mpm_run (_pconf=0x96730a8, plog=0x96a1160, s=0x9674f48) at prefork.c:975
#8  0x08061b08 in main (argc=3, argv=0xbff85a84) at main.c:717
In the pstack, gdb and gcore examples above, we can see that 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(). 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. For further details on advanced debugging techniques, please see the references.