httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeff Trawick <traw...@attglobal.net>
Subject core dump on daedalus Monday afternoon
Date Tue, 05 Feb 2002 12:33:35 GMT
I was attempting to put together a post like this yesterday when my
cable modem went out, and fortunately the cable didn't get restored at
the promised time so I got a good night's sleep.

Here is some basic information:

Reading symbols from /usr/libexec/ld-elf.so.1...done.
#0  0x80767be in core_input_filter (f=0x81243b8, b=0x8139798,
mode=AP_MODE_READBYTES,
    block=APR_BLOCK_READ, readbytes=54) at core.c:3144
3144            rv = apr_bucket_read(e, &str, &len, block);
(gdb) bt
#0  0x80767be in core_input_filter (f=0x81243b8, b=0x8139798,
mode=AP_MODE_READBYTES,
    block=APR_BLOCK_READ, readbytes=54) at core.c:3144
#1  0x806f534 in ap_get_brigade (next=0x81243b8, bb=0x8139798,
mode=AP_MODE_READBYTES,
    block=APR_BLOCK_READ, readbytes=54) at util_filter.c:418
#2  0x805ecce in ap_http_filter (f=0x813a318, b=0x8139798,
mode=AP_MODE_READBYTES,
    block=APR_BLOCK_READ, readbytes=54) at http_protocol.c:653
#3  0x806f534 in ap_get_brigade (next=0x813a318, bb=0x8139798,
mode=AP_MODE_READBYTES,
    block=APR_BLOCK_READ, readbytes=8192) at util_filter.c:418
#4  0x8076541 in net_time_filter (f=0x81397b8, b=0x8139798,
mode=AP_MODE_READBYTES,
    block=APR_BLOCK_READ, readbytes=8192) at core.c:3023
#5  0x806f534 in ap_get_brigade (next=0x81397b8, bb=0x8139798,
mode=AP_MODE_READBYTES,
    block=APR_BLOCK_READ, readbytes=8192) at util_filter.c:418
#6  0x8060015 in ap_get_client_block (r=0x8139048,
    buffer=0xbfbfd774 (junk), bufsiz=8192) 
    at http_protocol.c:1490
#7  0x281bd850 in cgi_handler (r=0x8139048) at mod_cgi.c:642
#8  0x8064d57 in ap_run_handler (r=0x8139048) at config.c:185
#9  0x80652f3 in ap_invoke_handler (r=0x8139048) at config.c:359
#10 0x806232c in ap_process_request (r=0x8139048) at
    http_request.c:290
#11 0x805dd5b in ap_process_http_connection (c=0x8124120) at
    http_core.c:287
#12 0x806d643 in ap_run_process_connection (c=0x8124120) at
    connection.c:84
#13 0x806d958 in ap_process_connection (c=0x8124120, csd=0x8124048) at
    connection.c:231
#14 0x8063854 in child_main (child_num_arg=78) at prefork.c:722
#15 0x80639ae in make_child (s=0x809a8d8, slot=78) at prefork.c:812
#16 0x8063bdd in perform_idle_server_maintenance (p=0x8099010) at
    prefork.c:953
#17 0x8063f56 in ap_mpm_run (_pconf=0x8099010, plog=0x80bf010,
    s=0x809a8d8) at prefork.c:1126
#18 0x8069676 in main (argc=1, argv=0xbfbffb18) at main.c:498
#19 0x805d965 in _start ()
(gdb)

We're trying to read from a sentinel bucket:

(gdb) p *ctx
$1 = {b = 0x81243f0}
(gdb) p e
$2 = (apr_bucket *) 0x81243f4

The client socket is all fubar.

(gdb) p *net
$4 = {client_socket = 0x81243f4, c = 0x81243f4, out_ctx = 0x2f602079,
in_ctx = 0x8124110}
(gdb) p *net->client_socket
$5 = {cntxt = 0x81243f4, socketdes = 135414772, type = 794828921,
local_addr = 0x8124110,
  remote_addr = 0x81243f0, timeout = 2885340802283391532,
local_port_unknown = 0,
  local_interface_unknown = 554, netmask = 554, inherit = 1414745936,
head = 0x48202f20,
  num_saved_buffers = 793793620}

(Those last two fields are from a debug patch.  Like the rest of the
fields, they are bogus.)

In fact, the entire net structure is foobar.  Look at the stuff it
supposedly points to besides client_socket:

(gdb) p *net
$6 = {client_socket = 0x81243f4, c = 0x81243f4, out_ctx = 0x2f602079,
in_ctx = 0x8124110}
(gdb) p *net->c
$7 = {pool = 0x81243f4, base_server = 0x81243f4, vhost_lookup_data =
0x2f602079,
  local_addr = 0x8124110, remote_addr = 0x81243f0, remote_ip =
0x280aca2c (junk), remote_logname = 0x0, aborted = 0,
  keepalive = 1, double_reverse = 1, keepalives = 554,
  local_ip = 0x54534f50 <Address 0x54534f50 out of bounds>,
  local_host = 0x48202f20 <Address 0x48202f20 out of bounds>, id =
  793793620,
  conn_config = 0xd302e31, notes = 0x6363410a, input_filters =
  0x3a747065,
  output_filters = 0x616d6920, sbh = 0x672f6567}
(gdb) p *net->out_ctx
Cannot access memory at address 0x2f602079.
(gdb) p *net->in_ctx
$8 = {b = 0x0}

That's all I can dig out at the moment.  I need to know more about how
net is supposed to be set up before I know which direction to go in
the dump.

-------------
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