You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "kang li (JIRA)" <ji...@apache.org> on 2014/05/23 14:55:02 UTC

[jira] [Created] (TS-2837) Dangling pointer in URLImpl which may cause core dump

kang li created TS-2837:
---------------------------

             Summary: Dangling pointer in URLImpl which may cause core dump
                 Key: TS-2837
                 URL: https://issues.apache.org/jira/browse/TS-2837
             Project: Traffic Server
          Issue Type: Bug
          Components: HTTP, Logging
            Reporter: kang li


There were core dump shows that URLImpl::m_ptr_printed_string was out of bound. 

{code}
#0  ink_strlcpy (dst=<value optimized out>, src=0x2b64901a79a4 <Address
0x2b64901a79a4 out of bounds>, siz=<value optimized out>)
    at ink_string.cc:226
#1  0x000000000058d820 in LogAccessHttp::init (this=0x2b631752da20) at
LogAccessHttp.cc:96
#2  0x000000000058a96f in resolve_logfield_string (context=0x2b631752da20,
    format_str=0x3468e10 "<!DOCTYPE html>\n<html lang=\"en-us\"><head>\n<meta
http-equiv=\"content-type\" content=\"text/html; charset=UTF-8\">\n    <meta
charset=\"utf-8\">\n    <title>Yahoo</title>\n    <meta name=\"viewport\"
content=\"wid"...) at LogAccess.cc:1396
#3  0x0000000000508fed in HttpBodyTemplate::build_instantiated_buffer
(this=0x3468de0, context=<value optimized out>,
    buflen_return=0x2b63e2c42068) at HttpBodyFactory.cc:1015
#4  0x0000000000509ea4 in HttpBodyFactory::fabricate (this=<value optimized
out>, acpt_language_list=0x2b631752e130,
    acpt_charset_list=0x2b631752dfd0, type=0x6d2c3d "connect#failed_connect",
context=0x2b63e2c416d8, buffer_length_return=0x2b63e2c42068,
    content_language_return=0x2b631752e2a8,
content_charset_return=0x2b631752e2a0, set_return=0x2b631752e298) at
HttpBodyFactory.cc:451
#5  0x000000000050b1b7 in HttpBodyFactory::fabricate_with_old_api(const char *,
HttpTransact::State *, int64_t, int64_t *, char *, size_t, char *, size_t,
const char *, typedef __va_list_tag __va_list_tag *) (this=0x344e850,
type=0x6d2c3d "connect#failed_connect",
    context=0x2b63e2c416d8, max_buffer_length=8192,
resulting_buffer_length=0x2b63e2c42068, content_language_out_buf=0x2b631752e460
"en",
    content_language_buf_size=256, content_type_out_buf=0x2b631752e360
"text/html", content_type_buf_size=256,
    format=0x6ce288 "internal error - server connection terminated",
ap=0x2b631752e590) at HttpBodyFactory.cc:137
#6  0x000000000054cd74 in HttpTransact::build_error_response (s=0x2b63e2c416d8,
status_code=HTTP_STATUS_BAD_GATEWAY,
    reason_phrase_or_null=0x6ce288 "internal error - server connection
terminated", error_body_type=<value optimized out>,
    format=0x6ce288 "internal error - server connection terminated") at
HttpTransact.cc:7998
#7  0x0000000000551b42 in HttpTransact::handle_server_connection_not_open
(s=0x2b63e2c416d8) at HttpTransact.cc:3719
#8  0x0000000000562f31 in HttpTransact::HandleResponse (s=0x2b63e2c416d8) at
HttpTransact.cc:3180
#9  0x000000000051c588 in HttpSM::call_transact_and_set_next_state
(this=0x2b63e2c41670, f=<value optimized out>) at HttpSM.cc:6817
#10 0x0000000000531f89 in HttpSM::state_http_server_open (this=0x2b63e2c41670,
event=201, data=0xffffffffffffff9d) at HttpSM.cc:1712
#11 0x0000000000530b38 in HttpSM::main_handler (this=0x2b63e2c41670, event=201,
data=0xffffffffffffff9d) at HttpSM.cc:2548
#12 0x00000000006878ec in handleEvent (this=0x2b64ac19f870, t=0x2b6315111010)
at ../../iocore/eventsystem/I_Continuation.h:146
#13 UnixNetVConnection::connectUp (this=0x2b64ac19f870, t=0x2b6315111010) at
UnixNetVConnection.cc:1104
#14 0x00000000006849ca in UnixNetProcessor::connect_re_internal (this=<value
optimized out>, cont=<value optimized out>,
    target=<value optimized out>, opt=0x2b631752f990) at
UnixNetProcessor.cc:250
#15 0x00000000005314ae in connect_re (this=0x2b63e2c41670, raw=<value optimized
out>) at ../../iocore/net/P_UnixNetProcessor.h:89
#16 HttpSM::do_http_server_open (this=0x2b63e2c41670, raw=<value optimized
out>) at HttpSM.cc:4676
#17 0x0000000000536446 in HttpSM::set_next_state (this=0x2b63e2c41670) at
HttpSM.cc:7006
#18 0x00000000005371ef in HttpSM::state_send_server_request_header
(this=0x2b63e2c41670, event=104, data=0x2b64144c7e28) at HttpSM.cc:2008
#19 0x0000000000530b38 in HttpSM::main_handler (this=0x2b63e2c41670, event=104,
data=0x2b64144c7e28) at HttpSM.cc:2548
#20 0x00000000006872a1 in handleEvent (event=<value optimized out>,
nh=0x2b6315114e20, vc=0x2b64144c7d20)
    at ../../iocore/eventsystem/I_Continuation.h:146
#21 read_signal_and_update (event=<value optimized out>, nh=0x2b6315114e20,
vc=0x2b64144c7d20) at UnixNetVConnection.cc:138
#22 read_signal_done (event=<value optimized out>, nh=0x2b6315114e20,
vc=0x2b64144c7d20) at UnixNetVConnection.cc:168
#23 0x0000000000689ab6 in read_from_net (nh=0x2b6315114e20, vc=0x2b64144c7d20,
thread=<value optimized out>) at UnixNetVConnection.cc:291
#24 0x0000000000682222 in NetHandler::mainNetEvent (this=0x2b6315114e20,
event=<value optimized out>, e=<value optimized out>)
    at UnixNet.cc:386
#25 0x00000000006a95cf in handleEvent (this=0x2b6315111010, e=0x2bdb270,
calling_code=5) at I_Continuation.h:146
#26 EThread::process_event (this=0x2b6315111010, e=0x2bdb270, calling_code=5)
at UnixEThread.cc:141
#27 0x00000000006a9fb3 in EThread::execute (this=0x2b6315111010) at
UnixEThread.cc:265
#28 0x00000000006a846a in spawn_thread_internal (a=0x2aaae30) at Thread.cc:88
#29 0x00002b630eb11851 in start_thread () from /lib64/libpthread.so.0
#30 0x000000355d0e894d in clone () from /lib64/libc.so.6
{code}

I found that may cause by HdrHeap::coalesce_str_heaps. As this would copy all HdrHeap m_read_write_heap and m_ronly_heap to a new heap and updated all related reference. The old heaps are also been released.  But URLImpl::m_ptr_printed_string haven't been updated. Once m_ptr_printed_string was assigned to a value, but coalesce didn't update the m_ptr_printed_string pointer. This would generate a dangling pointer. 

{code}
void
URLImpl::move_strings(HdrStrHeap * new_heap)
{
  HDR_MOVE_STR(m_ptr_scheme, m_len_scheme);
  HDR_MOVE_STR(m_ptr_user, m_len_user);
  HDR_MOVE_STR(m_ptr_password, m_len_password);
  HDR_MOVE_STR(m_ptr_host, m_len_host);
  HDR_MOVE_STR(m_ptr_port, m_len_port);
  HDR_MOVE_STR(m_ptr_path, m_len_path);
  HDR_MOVE_STR(m_ptr_params, m_len_params);
  HDR_MOVE_STR(m_ptr_query, m_len_query);
  HDR_MOVE_STR(m_ptr_fragment, m_len_fragment);
//    HDR_MOVE_STR(m_ptr_printed_string, m_len_printed_string);
}
{code}

The core dump is hard to reproduced but it related to error response from origin server.

The core dump shows that  in HttpTransact::build_error_response  the m_ptr_printed_string was first been assigned. And when calling it in LogAccessHttp::init. It was out of bound. Between HttpTransact::build_error_reponse to LogAccessHttp::init there were several times calling HdrHeap::allocate_str which may trigger HdrHeap::coalesce_str_heaps when there were no enough string heap in HdrHeap.



--
This message was sent by Atlassian JIRA
(v6.2#6252)