Jeff Trawick <[EMAIL PROTECTED]> writes:
> . Current code (worker MPM on Linux, at least) will segfault like
> crazy if you turn on APR_POOL_DEBUG and add "-lefence " to the
> beginning of EXTRA_LIBS in config_vars.mk (I guess this is the
> right way to use ElectricFence).
After sufficient sleep and/or caffiene, it occurred to me that I
should try a non-threaded build with efence and APR_POOL_DEBUG on this
Linux box. Sure enough, plentiful segfaults, but more importantly
usable coredumps...
I just fixed one of the causes of segfaults (bad parm in mod_rewrite)
(another misstep on my part though... in the hurry to try to find
the problem in different environments I neglected to modernize this
config file... but at least we got a fix out of it :) ).
I'm still getting this segfault:
#0 0x80ceb33 in core_input_filter (f=0x40af7fec, b=0x40c13ff4,
mode=AP_MODE_BLOCKING,
readbytes=0xbffff9c8) at core.c:2882
2882 APR_BRIGADE_NORMALIZE(ctx->b);
(gdb) where
#0 0x80ceb33 in core_input_filter (f=0x40af7fec, b=0x40c13ff4,
mode=AP_MODE_BLOCKING,
readbytes=0xbffff9c8) at core.c:2882
#1 0x80c56d9 in ap_get_brigade (next=0x40af7fec, bb=0x40c13ff4,
mode=AP_MODE_BLOCKING,
readbytes=0xbffff9c8) at util_filter.c:362
#2 0x80cea2b in net_time_filter (f=0x40c2dfec, b=0x40c13ff4,
mode=AP_MODE_BLOCKING,
readbytes=0xbffff9c8) at core.c:2844
#3 0x80c56d9 in ap_get_brigade (next=0x40c2dfec, bb=0x40c13ff4,
mode=AP_MODE_BLOCKING,
readbytes=0xbffff9c8) at util_filter.c:362
#4 0x80c6c38 in ap_rgetline (s=0x40b1fe9c, n=8192, r=0x40b1fe84,
fold=0) at protocol.c:225
#5 0x80c7227 in read_request_line (r=0x40b1fe84) at protocol.c:429
#6 0x80c789b in ap_read_request (conn=0x40aabfb8) at protocol.c:608
#7 0x807a2f9 in ap_process_http_connection (c=0x40aabfb8) at
http_core.c:273
#8 0x80c2f1d in ap_run_process_connection (c=0x40aabfb8) at
connection.c:84
#9 0x80c335d in ap_process_connection (c=0x40aabfb8) at
connection.c:230
#10 0x80b49e0 in child_main (child_num_arg=28) at prefork.c:716
#11 0x80b4b79 in make_child (s=0x41af9f9c, slot=28) at prefork.c:806
#12 0x80b4e74 in perform_idle_server_maintenance (p=0x4021afd8) at
prefork.c:947
#13 0x80b52be in ap_mpm_run (_pconf=0x4021afd8, plog=0x40797fd8,
s=0x41af9f9c)
at prefork.c:1118
#14 0x80bbd8e in main (argc=1, argv=0xbffffca4) at main.c:461
(gdb) p ctx
$1 = (core_ctx_t *) 0x40c43ffc
(gdb) p *ctx
$2 = {b = 0x40c49ff4}
(gdb)
This is fairly close to one of the segfaults I was trying to find
yesterday when I ended up going down other paths due to other bugs in
the server and due to missteps of my own.
That segfault has a similar traceback to the one shown above except
that it dies on this apr_bucket_read():
/* we are reading a single LF line, e.g. the HTTP headers */
while (!APR_BRIGADE_EMPTY(ctx->b)) {
const char *pos;
e = APR_BRIGADE_FIRST(ctx->b);
rv = apr_bucket_read(e, &str, &len, mode);
/* We should treat EAGAIN here the same as we do for EOF
(brigade is
have coredump, will debug...
--
Jeff Trawick | [EMAIL PROTECTED] | PGP public key at web site:
http://www.geocities.com/SiliconValley/Park/9289/
Born in Roswell... married an alien...
