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
