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 15:01:03 UTC
[jira] [Comment Edited] (TS-2837) Dangling pointer in URLImpl which
may cause core dump
[ https://issues.apache.org/jira/browse/TS-2837?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14007134#comment-14007134 ]
kang li edited comment on TS-2837 at 5/23/14 1:00 PM:
------------------------------------------------------
There are still core dump after the patch in TS-1411. Which seems to be the same issue.
was (Author: kang li):
There are still core dump after the patch in TS-1411.
> 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
> Affects Versions: 4.0.2
> 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)