https://bz.apache.org/bugzilla/show_bug.cgi?id=66601
--- Comment #3 from chengyech...@huawei.com ---
(In reply to Ruediger Pluem from comment #2)
> The pool should not be NULL here and just checking for NULL would probably
> hide the underlying bug. It looks like that the pool was already destroyed
> before.
thank you for reply
This problem seems to occur occasionally and has not recurred yet. In addition,
there is no debug log when the core dump occurs, and only the core dump file
can be viewed. But maybe because of the version, this file is not available to
you;
When I analyze the call stack step by step, I find that the pool is still 0x0
at layer 9 and that an address cannot be accessed at layer 10. As a result, the
analysis cannot continue.
(gdb) f 9
#9 0x0000aaaad8e7076c in ap_process_http_async_connection (c=0xfffef4000fa0)
at http_core.c:155
155 ap_process_async_request(r);
(gdb) p *(disk_cache_object_t *)((((cache_request_rec
*)r->output_filters->ctx)->handle)->cache_obj)->vobj
$41 = {root = 0xffff68015d38 "/var/cache/httpd/proxy", root_len = 22, prefix =
0x0, data = {pool = 0x0, file = 0xffff68015d70
"/var/cache/httpd/proxy/NP/ZG/fBHmUYzRXQL9t8q4Qw.data", fd = 0x0,
tempfile = 0x0, tempfd = 0x0}, hdrs = {pool = 0x0, file = 0xffff68015da8
"/var/cache/httpd/proxy/NP/ZG/fBHmUYzRXQL9t8q4Qw.header", fd = 0x0, tempfile =
0x0, tempfd = 0x0}, vary = {pool = 0x0,
file = 0xffff68015de0
"/var/cache/httpd/proxy/NP/ZG/fBHmUYzRXQL9t8q4Qw.header", fd = 0x0, tempfile =
0x0, tempfd = 0x0}, hashfile = 0xffff68015d50 "NP/ZG/fBHmUYzRXQL9t8q4Qw",
name = 0xffff68015d20 "https://sinon:443/?";, key = 0x0, file_size = 13,
disk_info = {format = 0, status = 0, name_len = 0, entity_version = 1, date =
0, expire = 0, request_time = 0,
response_time = 0, inode = 3019152, device = 64768, has_body = 1,
header_only = 0, control = {parsed = 0, cache_control = 0, pragma = 0, no_cache
= 0, no_cache_header = 0, no_store = 0,
max_age = 0, max_stale = 0, min_fresh = 0, no_transform = 0,
only_if_cached = 0, public = 0, private = 0, private_header = 0,
must_revalidate = 0, proxy_revalidate = 0, s_maxage = 0,
invalidated = 0, max_age_value = 0, max_stale_value = 0, min_fresh_value
= 0, s_maxage_value = 0}}, headers_in = 0xffff68016258, headers_out =
0xffff68016070, offset = 0, timeout = 0, done = 1}
(gdb) f 10
#10 ap_process_http_connection (c=0xfffef4000fa0) at http_core.c:246
246 return ap_process_http_async_connection(c);
(gdb) p *(cache_request_rec *)c->output_filters->ctx
$43 = {providers = 0x0, provider = 0x0, provider_name = 0x14 <error: Cannot
access memory at address 0x14>, fresh = 0, handle = 0x7d0, stale_handle = 0x0,
stale_headers = 0xffff82811048,
in_checked = -201323280, block_response = 65534, saved_brigade = 0x0,
saved_size = 187651414588256, exp = 281472426703872, lastmod = 281470480422544,
info = 0x0, save_filter = 0xfffef4000fa0,
remove_url_filter = 0xaaaaffe87788, key = 0xffff6801fc00 "", size =
281470480422320, out = 0x0, control_in = {parsed = 0, cache_control = 0, pragma
= 0, no_cache = 0, no_cache_header = 0,
no_store = 1, max_age = 0, max_stale = 1, min_fresh = 1, no_transform = 1,
only_if_cached = 1, public = 1, private = 0, private_header = 0,
must_revalidate = 0, proxy_revalidate = 0,
s_maxage = 0, invalidated = 0, max_age_value = 281470480419944,
max_stale_value = 281472426704032, min_fresh_value = 281472426704032,
s_maxage_value = 281472426576792}}
(gdb) p *((cache_request_rec *)c->output_filters->ctx)->handle
Cannot access memory at address 0x7d0
--
You are receiving this mail because:
You are the assignee for the bug.
---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscr...@httpd.apache.org
For additional commands, e-mail: bugs-h...@httpd.apache.org
