httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rasmus Lerdorf <ras...@lerdorf.on.ca>
Subject [No Subject]
Date Fri, 22 May 1998 11:40:47 GMT
I have been getting the odd core dump lately, and for a change I don't
think it is PHP's fault.  We had a PHP-related core dump problem for a
while, but it looks like we have fixed that particular problem.  Here is
the info on the current one:

#0  0x75c50 in ap_bgetopt (fb=0x2020346b, optname=1, optval=0x169e60) at buff.c:407
407             long int bs = fb->bytes_sent + fb->outcnt;
(gdb) bt
#0  0x75c50 in ap_bgetopt (fb=0x2020346b, optname=1, optval=0x169e60) at buff.c:407
#1  0x8df34 in ap_rprintf (r=0x169e10, fmt=0xdfab0 "%4dk") at http_protocol.c:1853
#2  0x9b34c in ap_send_size (size=3949, r=0x169e10) at util_script.c:550
#3  0x330cc in output_directories (ar=0x174750, n=649, d=0x1405a8, r=0x169e10, autoindex_opts=1,
keyid=78 'N', direction=65 'A')
    at mod_autoindex.c:920
#4  0x33890 in index_directory (r=0x169e10, autoindex_conf=0x1405a8) at mod_autoindex.c:1123
#5  0x33a60 in handle_autoindex (r=0x169e10) at mod_autoindex.c:1164
#6  0x790c8 in ap_invoke_handler (r=0x169e10) at http_config.c:503
#7  0x91ae4 in process_request_internal (r=0x169e10) at http_request.c:1164
#8  0x91b38 in ap_process_request (r=0x169e10) at http_request.c:1181
#9  0x874cc in child_main (child_num_arg=22) at http_main.c:3618
#10 0x877f8 in make_child (s=0x13f770, slot=22, now=895770663) at http_main.c:3738
#11 0x87cf0 in perform_idle_server_maintenance () at http_main.c:3893
#12 0x88408 in standalone_main (argc=2, argv=0xeffffc64) at http_main.c:4120
#13 0x88b44 in main (argc=2, argv=0xeffffc64) at http_main.c:4289

That fb address is quite bogus.  This comes from the SET_BYTES_SENT()
macro call which passes on r->connection->client which is somehow bogus.
Other parts of the request_rec look ok.  Here it is:

(gdb) p *r
$2 = {pool = 0x169de8, connection = 0x168dd0, server = 0x15cff8, next =
0x0, prev = 0x0, main = 0x0, 
  the_request = 0x16a520 "GET /manual/ HTTP/1.1", assbackwards = 0,
proxyreq = 0, header_only = 0, protocol = 0x16a570 "HTTP/1.1", 
  proto_num = 1001, hostname = 0x16a6d0 "www.php3.com", request_time =
895815820, status_line = 0xdddb0 "200 OK", status = 200, 
  method = 0x16a538 "GET", method_number = 0, allowed = 1, sent_bodyct =
1, bytes_sent = 20341, mtime = 0, chunked = 1, 
  byterange = 0, boundary = 0x0, range = 0x0, clength = 0, remaining = 0,
read_length = 0, read_body = 0, read_chunked = 0, 
  headers_in = 0x169f90, headers_out = 0x16a2e0, err_headers_out =
0x16a358, subprocess_env = 0x16a138, notes = 0x16a398, 
  content_type = 0xc2ab8 "text/html", handler = 0x0, content_encoding =
0x0, content_language = 0x0, content_languages = 0x0, 
  no_cache = 0, no_local_copy = 0, unparsed_uri = 0x16a550 "/manual/", uri
= 0x16a560 "/manual/", 
  filename = 0x16a8b8 "/u/www/servers/lerdorf/php3/manual/", path_info =
0x16a740 "/", args = 0x0, finfo = {st_dev = 42729473, 
    st_pad1 = {0, 0, 0}, st_ino = 2670357, st_mode = 16877, st_nlink = 3,
st_uid = 0, st_gid = 1, st_rdev = 0, st_pad2 = {0, 0}, 
    st_size = 36864, st_pad3 = 0, st_atim = {tv_sec = 895792608, tv_nsec =
980000000}, st_mtim = {tv_sec = 895573002, 
      tv_nsec = 230001000}, st_ctim = {tv_sec = 895573002, tv_nsec =
230001000}, st_blksize = 8192, st_blocks = 72, 
    st_fstype = "nfs", '\000' <repeats 12 times>, st_pad4 = {0, 0, 0, 0,
0, 0, 0, 0}}, parsed_uri = {scheme = 0x0, hostinfo = 0x0, 
    user = 0x0, password = 0x0, hostname = 0x0, port_str = 0x0, path =
0x16a560 "/manual/", query = 0x0, fragment = 0x0, 
    hostent = 0x0, port = 0, is_initialized = 1, dns_looked_up = 0,
dns_resolved = 0}, per_dir_config = 0x16a770, 
  request_config = 0x16a3d8, htaccess = 0x0}
(gdb) p r->connection
$3 = (conn_rec *) 0x168dd0
(gdb) p *r->connection
$4 = {pool = 0x2020326b, server = 0x20202031, base_server = 0x6b202020,
vhost_lookup_data = 0x316b2020, child_num = 540109600, 
  client = 0x2020346b, local_addr = {sin_family = 2, sin_port = 80,
sin_addr = {S_un = {S_un_b = {s_b1 = 207 'Ï', s_b2 = 164 '¤', 
          s_b3 = 55 '7', s_b4 = 5 '\005'}, S_un_w = {s_w1 = 53156, s_w2 =
14085}, S_addr = 3483645701}}, 
    sin_zero = "\000\000\000\000\000\000\000"}, remote_addr = {sin_family
= 2, sin_port = 40859, sin_addr = {S_un = {S_un_b = {
          s_b1 = 209 'Ñ', s_b2 = 57 '9', s_b3 = 242 'ò', s_b4 = 246 'ö'},
S_un_w = {s_w1 = 53561, s_w2 = 62198}, 
        S_addr = 3510235894}}, sin_zero = "\000\000\000\000\000\000\000"},
remote_ip = 0x168e28 "209.57.242.246", 
  remote_host = 0x0, remote_logname = 0x0, user = 0x0, ap_auth_type = 0x0,
aborted = 0, keepalive = 1, keptalive = 0, 
  double_reverse = 0, keepalives = 7}
(gdb) p *r->connection->client
Cannot access memory at address 0x2020346b.

Does this ring any bells for anybody?  If anybody wants to see other vars
from the core, let me know, or if you want the core and the binary to play
with yourself, I can provide the files.  This is from a Solaris 2.5.1 box
and the compiler is gcc-2.8.1.

-Rasmus


Mime
View raw message