On Mon, Jan 26, 2004 at 10:05:33PM +0000, Colm MacCarthaigh wrote:
disable the check for geteuid()==0 and see if you get backtrace? exception hook purposefully doesn't run as root (I assume your parent is running as root)
No problem, first thing tomorrow :)
O.k., done that, and now have a useful backtrace (might we worth adding a #define to turn those checks off):
yeah... note that it looks like apache-1.3 is about to get the hook too, but it is enabled via a directive in httpd.conf (EnableExceptionHook {on|off}).. maybe a special keyword like AllUids could be used to enable the hook for root without rebuilding the server...
backtrace for signal 11 from process 0 (parent 7786, thread "pid" 7789) main() is at 808e124 /usr/local/web/modules/mod_backtrace.so[0x550149bf] /usr/local/web/modules/mod_backtrace.so[0x55014a34] /usr/local/web/bin/httpd(ap_run_fatal_exception+0x30)[0x80947f8] /usr/local/web/bin/httpd[0x8094847] /usr/local/web/bin/httpd[0x8094880]
not enough entries in backtrace :) I guess that is a stack corruption issue?
Attaching gdb to the running process before it dies gets me nowhere:
Program received signal SIGSEGV, Segmentation fault. 0x00000008 in ?? ()
yeah, been there done that seen that :(
I've been debugging similar problem with 2.0.47 for the last day or so... took a while to happen upon your discussion within the innocuous thread "[PATCH] raise MAX_SERVER_LIMIT" ;)
I don't have any hard data yet other than to say I see something roughly similar under load and something is corrupted with stackframes preventing cores or controlling parent under gdb or apparently any other standard techniques from shedding any light on the issue. I'll be adding some sort of tracing to find out more closely what the parent is doing when it crashes.
Yesterday I had strace running on parent at the time and the last syscall showed it killing a child via write("!"), then SIGSEGV.
