httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject Re: pool problems with HEAD??
Date Fri, 11 Jan 2002 13:45:47 GMT
Jeff Trawick <trawick@attglobal.net> 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 | trawick@attglobal.net | PGP public key at web site:
       http://www.geocities.com/SiliconValley/Park/9289/
             Born in Roswell... married an alien...

Mime
View raw message