Bug 59164 - If tomcat server can not be resolved, crash occurred.
Summary: If tomcat server can not be resolved, crash occurred.
Status: RESOLVED FIXED
Alias: None
Product: Tomcat Connectors
Classification: Unclassified
Component: mod_jk (show other bugs)
Version: 1.2.41
Hardware: PC Linux
: P2 normal (vote)
Target Milestone: ---
Assignee: Tomcat Developers Mailing List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-03-11 02:00 UTC by Hiroto Shimizu
Modified: 2016-09-13 21:29 UTC (History)
2 users (show)



Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Hiroto Shimizu 2016-03-11 02:00:32 UTC
If host names were not resolved , and first access(curl http://localhost/).
After that , crash occurred.
This behavior is 1.2.38 or later.

---configuration
JkMount /* worker1
worker.list=worker1
worker.worker1.type=ajp13
worker.worker1.host=testhost
---

---mod_jk.log
[Tue Feb 23 17:24:08.475 2016] [14936:140647557949504] [error] ajp_validate::jk_ajp_common.c (2867): worker worker1 can't resolve tomcat address testhost
[Tue Feb 23 17:24:08.475 2016] [14936:140647557949504] [info] init_jk::mod_jk.c (3591): mod_jk/1.2.41 initialized
[Tue Feb 23 17:24:08.509 2016] [14936:140647557949504] [error] ajp_validate::jk_ajp_common.c (2867): worker worker1 can't resolve tomcat address testhost
[Tue Feb 23 17:24:08.510 2016] [14936:140647557949504] [info] init_jk::mod_jk.c (3591): mod_jk/1.2.41 initialized
[Tue Feb 23 17:24:25.218 2016] [14938:140647313106688] [error] jk_open_socket::jk_connect.c (639): socket() failed (errno=97)
---

---error_log
[Tue Feb 23 17:24:08.511135 2016] [mpm_worker:notice] [pid 14936:tid 140647557949504] AH00292: Apache/2.4.6 (CentOS) mod_jk/1.2.41 configured -- resuming normal operations
[Tue Feb 23 17:24:08.511173 2016] [core:notice] [pid 14936:tid 140647557949504] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND'
[Tue Feb 23 17:24:26.531681 2016] [core:notice] [pid 14936:tid 140647557949504] AH00051: child pid 14938 exit signal Segmentation fault (11), possible coredump in /tmp
---

Hostname were not resolved in apr_sockaddr_info_get() , and JK_FALSE is returned.
inet_ntop6() caused segmentation fault, because of saddr=null.

---jk_connect.c
:
int jk_resolve(const char *host, int port, jk_sockaddr_t *saddr,
               void *pool, int prefer_ipv6, jk_logger_t *l)
{
:
    memset(saddr, 0, sizeof(jk_sockaddr_t));
:
        if (apr_sockaddr_info_get(&remote_sa, host, APR_UNSPEC, (apr_port_t)port,
                                  0, jk_apr_pool) != APR_SUCCESS) {
            JK_TRACE_EXIT(l);
            return JK_FALSE;
        }
---

---
# gdb /usr/sbin/httpd core.14938
:
(gdb) bt
#0  inet_ntop6 (src=0x0, dst=dst@entry=0x7feb0122c750 "\030", size=size@entry=64) at jk_connect.c:1201
#1  0x00007feb02289691 in jk_dump_hinfo (saddr=0x7feb1013e258, buf=buf@entry=0x7feb0122c750 "\030", size=size@entry=64) at jk_connect.c:1293
#2  0x00007feb022a7fcb in ajp_connect_to_endpoint (ae=ae@entry=0x7feb1019e1a0, l=l@entry=0x7feb1016e840) at jk_ajp_common.c:1068
#3  0x00007feb022a93ab in ajp_send_request (e=0x7feb101a01f0, op=<synthetic pointer>, ae=0x7feb1019e1a0, l=0x7feb1016e840, s=0x7feb0122c9e0) at jk_ajp_common.c:1727
#4  ajp_service (e=0x7feb101a01f0, s=0x7feb0122c9e0, l=0x7feb1016e840, is_error=0x7feb0122c994) at jk_ajp_common.c:2639
:
(gdb) f 1
#1  0x00007feb02289691 in jk_dump_hinfo (saddr=0x7feb1013e258, buf=buf@entry=0x7feb0122c750 "\030", size=size@entry=64) at jk_connect.c:1293
1293            inet_ntop6(saddr->ipaddr_ptr, buf, size);
(gdb) p *saddr
$1 = {family = 0, port = 0, salen = 0, ipaddr_len = 0, ipaddr_ptr = 0x0, sa = {sin = {sin_family = 0, sin_port = 0, sin_addr = {s_addr = 0},
      sin_zero = "\000\000\000\000\000\000\000"}, sin6 = {sin6_family = 0, sin6_port = 0, sin6_flowinfo = 0, sin6_addr = {__in6_u = {__u6_addr8 = '\000' <repeats 15 times>,
          __u6_addr16 = {0, 0, 0, 0, 0, 0, 0, 0}, __u6_addr32 = {0, 0, 0, 0}}}, sin6_scope_id = 0}, sas = {ss_family = 0, __ss_align = 0, __ss_padding = '\000' <repeats 111 times>}}}
---
Comment 1 Mark Thomas 2016-09-13 21:29:40 UTC
Thanks for the report and the back trace. This has been fixed in trunk and will be included in 1.2.42 onwards.