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):
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]
/lib/libpthread.so.0[0x550daf54]
/lib/libc.so.6[0x551126b8]
end of backtrace from process 0
None of the addresses seem to translate to anything useful nm can
produce, I tried subtracting their offset, using only the high-order
bits, using only the low order bits, but it got me nowhere :/ A corefile
backtrace in gdb get me:
#0 0x0808856b in server_main_loop (remaining_children_to_start=Cannot
access memory at address 0xb)
at worker.c:1545
1545 ap_wait_or_timeout(&exitwhy, &status, &pid, pconf);
Attaching gdb to the running process before it dies gets me
nowhere:
Program received signal SIGSEGV, Segmentation fault.
0x00000008 in ?? ()
is all I get when it happens. No backtrace available :( I have however
managed to get the tcpdump of the period - which is 484Megs for about
5 minutes of runtime (it's a busy box!), if anyone wants it - mail
and I'll supply. In the meantime, I'm going to scour the code once
more, to see if there's anything I missed the last 10 times :)
--
Colm MacC�rthaigh Public Key: [EMAIL PROTECTED]
