I'm trying to investigate some core dumps in mod_security and currently
face this
(gdb) bt
#0 0xf6efc232 in create_tx_context (r=0x1eac8ed0) at mod_security2.c:325
#1 0xf6efc606 in hook_error_log (file=0x80a51bd "http_filters.c",
line=493, level=3, status=104, s=0x18144178, r=0x1eac8ed0, mp=0x0,
fmt=0xeb2f6dff "Error reading chunk \n")
at mod_security2.c:771
#2 0x08080c2d in ap_run_error_log (file=0x80a51bd "http_filters.c",
line=493, level=3, status=104, s=0x18144178, r=0x1eac8ed0, pool=0x0,
errstr=0xeb2f6dff "Error reading chunk \n") at log.c:1116
#3 0x0808109b in log_error_core (file=0x80a51bd "http_filters.c",
line=493, level=<optimized out>, status=104, s=0x18144178, c=0x0,
r=0x1eac8ed0, pool=0x0,
fmt=0x80a52a1 "Error reading chunk %s ", args=0xeb2f8e08
"hT\n\b\230L\255\036\177\017\275\036\376\001") at log.c:705
#4 0x08081ec1 in ap_log_rerror (file=0x80a51bd "http_filters.c", line=493,
level=3, status=104, r=0x1eac8ed0, fmt=0x80a52a1 "Error reading chunk %s ")
at log.c:737
#5 0x0808d400 in ap_http_filter (f=0x1eaca3b0, b=0x1eac8eb0,
mode=AP_MODE_READBYTES, block=APR_NONBLOCK_READ, readbytes=8192) at
http_filters.c:493
#6 0xf716bfe6 in ap_proxy_http_process_response (p=0x1eab4cd8,
r=0x1eab4d18, backend=0x9241848, origin=0x929ab40, conf=0x1e8db5e0,
server_portstr=0xeb2fd107 "")
at mod_proxy_http.c:1771
#7 0xf716d609 in proxy_http_handler (r=0x1eab4d18, worker=0x13db7be8,
conf=0x1e8db5e0, url=0x1eac8950 "/a/b/WebService", proxyname=0x0,
proxyport=<optimized out>) at mod_proxy_http.c:2037
#8 0xf72daec0 in proxy_run_scheme_handler (r=0x1eab4d18,
worker=0x13db7be8, conf=0x1e8db5e0, url=0x1eac8878 "
http://10.10.10.10:8080/a/b/WebService<http://10.21.9.205:8080/tourconex/services/TourConexWebService>",
proxyhost=0x0, proxyport=0) at mod_proxy.c:2455
#9 0xf72dfdbb in proxy_handler (r=0x1eab4d18) at mod_proxy.c:1023
#10 0x0807cdc1 in ap_run_handler (r=0x1eab4d18) at config.c:157
#11 0x080802c6 in ap_invoke_handler (r=0x1eab4d18) at config.c:376
#12 0x0808b6d0 in ap_process_request (r=0x1eab4d18) at http_request.c:282
#13 0x080886e8 in ap_process_http_connection (c=0x1eaaaea8) at
http_core.c:190
#14 0x08084571 in ap_run_process_connection (c=0x1eaaaea8) at
connection.c:43
#15 0x08091aac in process_socket (bucket_alloc=<optimized out>,
my_thread_num=<optimized out>, my_child_num=<optimized out>,
sock=<optimized out>, p=<optimized out>)
at worker.c:544
#16 worker_thread (thd=0x1e96ac40, dummy=0x1ea48678) at worker.c:894
#17 0xf7575ac6 in dummy_worker (opaque=0x1e96ac40) at
threadproc/unix/thread.c:142
#18 0xf74fc809 in start_thread () from /lib/libpthread.so.0
#19 0xf745d30e in clone () from /lib/libc.so.6
Backtrace stopped: Not enough registers or memory available to unwind
further
(gdb) print r->per_dir_config
$1 = (struct ap_conf_vector_t *) 0x0
where the offending line of code is
msr->dcfg1 = (directory_config *)ap_get_module_config(r->per_dir_config,
&security2_module);
Why would the per_dir_config be NULL here ? I don't think that should ever
be encountered during the request's lifetime, right ?
My confusion continued when I saw
(gdb) print *r
$2 = {pool = 0x1eab4cd8, connection = 0x929ab40, server = 0x18144178, next
= 0x0, prev = 0x0, main = 0x0, the_request = 0x0, assbackwards = 0,
proxyreq = 3, header_only = 0,
protocol = 0x0, proto_num = 0, hostname = 0x0, request_time =
1368183918343107, status_line = 0x0, status = 200, method = 0x0,
method_number = 0, allowed = 0,
allowed_xmethods = 0x0, allowed_methods = 0x0, sent_bodyct = 0,
bytes_sent = 0, mtime = 0, chunked = 0, range = 0x0, clength = 0, remaining
= 0, read_length = 0,
read_body = 0, read_chunked = 0, expecting_100 = 0, headers_in =
0x1ebcee40, headers_out = 0x1eac9750, err_headers_out = 0x1eac98f8,
subprocess_env = 0x1eac93e0,
notes = 0x1eac9a50, content_type = 0x0, handler = 0x0, content_encoding =
0x0, content_languages = 0x0, vlist_validator = 0x0, user = 0x0,
ap_auth_type = 0x0, no_cache = 0,
no_local_copy = 0, unparsed_uri = 0x0, uri = 0x0, filename = 0x0,
canonical_filename = 0x0, path_info = 0x0, args = 0x0, finfo = {pool = 0x0,
valid = 0, protection = 0,
filetype = APR_NOFILE, user = 0, group = 0, inode = 0, device = 0,
nlink = 0, size = 0, csize = 0, atime = 0, mtime = 0, ctime = 0, fname =
0x0, name = 0x0,
filehand = 0x0}, parsed_uri = {scheme = 0x0, hostinfo = 0x0, user =
0x0, password = 0x0, hostname = 0x0, port_str = 0x0, path = 0x0, query =
0x0, fragment = 0x0,
hostent = 0x0, port = 0, is_initialized = 0, dns_looked_up = 0,
dns_resolved = 0}, used_path_info = 0, per_dir_config = 0x0, request_config
= 0x1eac9ba8, htaccess = 0x0,
output_filters = 0x929aff8, input_filters = 0x1eaca3b0,
proto_output_filters = 0x929aff8, proto_input_filters = 0x1eaca3b0,
eos_sent = 0}
(gdb) dump_table(r->headers_in)
[0] 'Server'='Apache-Coyote/1.1' [0x1eaca1e0]
[1] 'X-Powered-By'='Servlet 2.4; JBoss-4.2.2.GA (build:
SVNTag=JBoss_4_2_2_GA date=200710221139)/Tomcat-5.5' [0x1eaca218]
[2] 'Content-Type'='text/xml;charset=utf-8' [0x1eaca290]
[3] 'Transfer-Encoding'='chunked' [0x1eaca2d0]
[4] 'Date'='Fri, 10 May 2013 11:05:59 GMT' [0x1eaca310]
A 'Server' header in the headers_in field, isn't that just nonsense ? Also
note the NULLs in for protocol and proto_num which I don't think should be
there.
I got the feeling something was really wrong with that request, long before
mod_security got to see it. Unfortunately, I don't know the circumstances
of the request since I only have access to the coredump file and nothing
else.
Any hint on how to proceed with this, e.g. what to inspect ? I don't think
it's only per_dir_config screwed up here.
Cheers & thanks,
Thomas
