httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@raleigh.ibm.com>
Subject Re: apache.org: assert popped in bucket land
Date Fri, 16 Feb 2001 23:21:48 GMT
OK, it makes a little more sense to me now, but I'm still a long way
from the bug.

(gdb) frame 3
#3  0x8060004 in ap_setup_client_block (r=0x813703c, read_policy=2)
    at http_protocol.c:2722
2722            AP_DEBUG_ASSERT(APR_BRIGADE_EMPTY(req_cfg->bb));
(gdb) p req_cfg
$12 = (core_request_config *) 0x0
(gdb) p r->the_request
$13 = 0x813782c "GET /resources/script.js HTTP/1.0"
(gdb) p r->status
$15 = 200
(gdb) p r->hostname
$16 = 0x0 
(gdb) dump_table r->headers_in
(gdb)  

req_cfg shouldn't be 0 here.  It is initialized in ap_read_request when
the r is initialized.  Since we are into the default_handler already, I
would think that the headers should have been read & parsed.  The URI
would be valid in xml.apache.org, but if there really isn't a Host:
header, I don't know how we know to go there.   

hmmmm....maybe I should try a telnet request like this with no headers
and see what happens.  After I sleep.

Greg

Greg Ames wrote:
> 
> Here's the backtrace from the second core dump from apache.org.  looks
> like Hungarian lisp to me so far.
> 
> (gdb) bt
> #0  0x2812a3c8 in kill () from /usr/lib/libc.so.4
> #1  0x2816609e in abort () from /usr/lib/libc.so.4
> #2  0x80683ee in ap_log_assert (
>     szExp=0x80964e0 "(((&(req_cfg->bb)->list))->next == (struct
> apr_bucket *)((char *)((&(req_cfg->bb)->list)) - ((size_t)(&((struct
> apr_bucket *)0)-> link))))",
>     szFile=0x80962e0 "http_protocol.c", nLine=2722) at log.c:562
> #3  0x8060004 in ap_setup_client_block (r=0x813703c, read_policy=2)
>     at http_protocol.c:2722
> #4  0x80602f5 in ap_discard_request_body (r=0x813703c) at
> http_protocol.c:2868
> #5  0x805bb4e in default_handler (r=0x813703c) at http_core.c:2975
> #6  0x8065658 in ap_run_handler (r=0x813703c) at config.c:131
> #7  0x80659d3 in ap_invoke_handler (r=0x813703c) at config.c:300
> #8  0x8063278 in process_request_internal (r=0x813703c) at
> http_request.c:1367
> #9  0x8063327 in ap_process_request (r=0x813703c) at http_request.c:1406
> #10 0x806d58b in ap_process_http_connection (c=0x81310ec) at
> connection.c:244
> #11 0x806d398 in ap_run_process_connection (c=0x81310ec) at
> connection.c:82
> #12 0x806d4fc in ap_process_connection (c=0x81310ec) at connection.c:216
> #13 0x806446e in child_main (child_num_arg=86) at prefork.c:796
> #14 0x806459d in make_child (s=0x80b4514, slot=86) at prefork.c:869
> #15 0x8064795 in perform_idle_server_maintenance () at prefork.c:1010
> #16 0x8064ab1 in ap_mpm_run (_pconf=0x80b400c, plog=0x80de00c,
> s=0x80b4514)
>     at prefork.c:1180
> #17 0x8068f0c in main (argc=1, argv=0xbfbff9fc) at main.c:428
> #18 0x8058af5 in _start ()
> 
> Greg

Mime
View raw message