httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Greg Ames <grega...@remulak.net>
Subject Re: 2.0.26 was in production briefly tonight
Date Fri, 19 Oct 2001 21:05:43 GMT
Greg Ames wrote:

> All three of the dumps last night were for requests to
> http://xml.apache.org/cocoon/dist . 

>  I still get seg faults even after the latest core.c fix.

> #1  0x280bb9d6 in apr_array_append (p=0x81cd00c, first=0x8158b84,
> second=0x0)
>     at apr_tables.c:209
> #2  0x806fe28 in merge_core_dir_configs (a=0x81cd00c, basev=0x8158b24,
>     newv=0x81cdd00) at core.c:286

newv looks very dodgy.   

(gdb) p * (core_dir_config *) newv
$4 = {d = 0x6c6d782f <Address 0x6c6d782f out of bounds>,
  d_components = 1634754862, opts = 99 'c', opts_add = 104 'h',
  opts_remove = 101 'e', override = 46 '.',
  ap_default_type = 0x2f67726f <Address 0x2f67726f out of bounds>,
  satisfy = 1868787555,
  ap_auth_type = 0x642f6e6f <Address 0x642f6e6f out of bounds>,
  ap_auth_name = 0x747369 <Address 0x747369 out of bounds>,
  ap_requires = 0x81cdd00, response_code_strings = 0x0, hostname_lookups
= 0,
  do_rfc1413 = 0, content_md5 = 0, use_canonical_name = 0, d_is_fnmatch
= 0,
  add_default_charset = 0, add_default_charset_name = 0x0, limit_cpu =
0x0,
  limit_mem = 0x0, limit_nproc = 0x0, limit_req_body = 0, limit_xml_body
= 0,
  server_signature = srv_sig_unset, loglevel = 0, sec_file = 0x0, r =
0x0,
  mime_type = 0x0, handler = 0x0, output_filters = 0x0, input_filters =
0x0}

sec_file is where we pick up the fatal zeros. But look at the bytes
starting with opts - "che."
If I print newv out as a string I get:

(gdb) x/s newv
0x81cdd00:       "/xml.apache.org/cocoon/dist"

> #3  0x8063217 in ap_merge_per_dir_configs (p=0x81cd00c, base=0x8158a74,
>     new_conf=0x8144a5c) at config.c:262
> #4  0x8075e5a in ap_directory_walk (r=0x81cd03c) at request.c:937

936         if (now_merged)
937             r->per_dir_config = ap_merge_per_dir_configs(r->pool,
938                                                         
r->per_dir_config,
939                                                         
now_merged);

now_merged is bad:

(gdb) p (core_dir_config *) now_merged[0]
$15 = (core_dir_config *) 0x81cdd00
(gdb) x/s 0x81cdd00
0x81cdd00:       "/xml.apache.org/cocoon/dist"

hmmmm, we never see the URL in the server AFAIK.  But we do see the
filename.  

(gdb) p r->filename
$18 = 0x81cdcfc "/www/xml.apache.org/cocoon/dist"

hey! that address is (&core_dir_config) - 4.  Maybe all that time I
squandered in my youth doing hex arithmetic is finally paying off.

I'm guessing r->filename came from a straightforward p(c)alloc. So it
sounds like we've got a bogus core_dir_config pointer.

Tracking it back farther than this is going to be hard, for me anyway,
because now_merged is set in a bunch of places throughout
ap_directory_walk().  All I can think of is writing an "is it broke
yet?" trap that verifies something in the core_dir_config every time
now_merged is set.  Maybe ap_default_type, since it looks like it got
whacked with the filename.  

I think that if there is a non-null core_dir_config pointer,
ap_default_type should be either: 

* null,
* a pointer to memory we can access, or 
* it's broken.

Greg

Mime
View raw message