httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Behlendorf <>
Subject core dumps with current CVS tree and gcc 2.8.1
Date Mon, 20 Apr 1998 15:30:54 GMT

I didn't want to post something here until I knew for sure, but I'm sure
there's something wrong now.  Over the last week the server on
(which I've been keeping in sync with the cvs tree) at various times has
gone haywire, with a number of child processes running away with the CPU,
and no responses to HTTP requests until a complete (kill -15) restart of
the server takes place.  Some of the children core dump around the same
time, producing a core file with the following rather weird backtrace:

taz% gdb /usr/local/bin/apache /var/tmp/apache.core 
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.16 (i386-unknown-freebsd2.2.6), 
Copyright 1996 Free Software Foundation, Inc...
Core was generated by `apache'.
Program terminated with signal 6, Abort trap.
Cannot access memory at address 0x20062080.
#0  0x200d2731 in ?? ()
(gdb) where
#0  0x200d2731 in ?? ()
#1  0x200d1fa4 in ?? ()
#2  0x3a8ba in sig_coredump (sig=10) at http_main.c:2187
#3  0xefbfdfdc in ?? ()
#4  0x200bc29e in ?? ()
#5  0x200bc496 in ?? ()
#6  0x200bc894 in ?? ()
#7  0x43060 in ap_get_time () at util.c:117
#8  0x35f4e in ap_log_error (file=0x366b8 "http_main.c", line=3693, level=11, 
    fmt=0x3905f "server reached MaxClients setting, consider raising the
MaxClients setting") at http_log.c:318
#9  0x392db in perform_idle_server_maintenance () at http_main.c:3693
#10 0x39a11 in standalone_main (argc=3, argv=0xefbfdbec) at http_main.c:3878
#11 0x3a0eb in main (argc=3, argv=0xefbfdbec) at http_main.c:4039

I know ap_get_time is one of Dean's favorite pieces of code :)

The runaway processes and core dumps started happening around the same time
as the OS upgrade, various security fixes, and the installation of gcc
2.8.1 - and if I had to point to an external factor as a cause I'd probably
point to gcc 2.8.1.  I'm going to recompile with gcc and see if I
still get the instability.  Oddly enough the problems seem to manifest
themselves every weekday morning around 5am or so PST, though I can't find
a connection...


"Optimism is a strategy for making               
a better future." - Noam Chomsky              

View raw message