[
https://issues.apache.org/jira/browse/TS-2792?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13996138#comment-13996138
]
Masakazu Kitajo commented on TS-2792:
-------------------------------------
{noformat}
(gdb) b url_rewrite_remap_request
Breakpoint 1 at 0x5ea830: file UrlRewrite.cc, line 288.
(gdb) r
Starting program: /usr/local/trafficserver/bin/traffic_server
[Thread debugging using libthread_db enabled]
[TrafficServer] using root directory '/usr/local/trafficserver'
[New Thread 0x7ffff6bd3700 (LWP 26844)]
Can't change user to 'nobody' because running with effective uid=14777
[New Thread 0x7ffff5dce700 (LWP 26845)]
[New Thread 0x7ffff5ccd700 (LWP 26846)]
[New Thread 0x7ffff3da6700 (LWP 26847)]
[New Thread 0x7ffff3ba4700 (LWP 26848)]
[New Thread 0x7ffff39a2700 (LWP 26849)]
[New Thread 0x7ffff37a0700 (LWP 26850)]
[New Thread 0x7ffff359e700 (LWP 26851)]
[New Thread 0x7ffff339c700 (LWP 26852)]
[New Thread 0x7ffff319a700 (LWP 26853)]
[New Thread 0x7ffff2f98700 (LWP 26854)]
[New Thread 0x7ffff2d96700 (LWP 26855)]
[New Thread 0x7ffff2b94700 (LWP 26856)]
[New Thread 0x7ffff250e700 (LWP 26857)]
[New Thread 0x7ffff21b3700 (LWP 26858)]
[New Thread 0x7ffff20b2700 (LWP 26859)]
[New Thread 0x7ffff1eb0700 (LWP 26860)]
[Switching to Thread 0x7ffff5ccd700 (LWP 26846)]
Breakpoint 1, url_rewrite_remap_request (mapping_container=...,
request_url=0x7ffff1d2c128) at UrlRewrite.cc:288
288 {
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.132.el6.x86_64
hwloc-1.5-1.el6.x86_64 keyutils-libs-1.4-4.el6.x86_64
krb5-libs-1.10.3-15.el6_5.1.x86_64 libattr-2.4.44-7.el6.x86_64
libcap-2.16-5.5.el6.x86_64 libcom_err-1.41.12-18.el6.x86_64
libgcc-4.4.7-4.el6.x86_64 libselinux-2.0.94-5.3.el6_4.1.x86_64
libstdc++-4.4.7-4.el6.x86_64 nss-softokn-freebl-3.14.3-10.el6_5.x86_64
numactl-2.0.7-8.el6.x86_64 openssl-1.0.1e-16.el6_5.7.x86_64
pciutils-libs-3.1.10-2.el6.x86_64 pcre-7.8-6.el6.x86_64 tcl-8.5.7-6.el6.x86_64
xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) p *request_url->m_heap
$1 = {m_magic = 2882404077, m_free_start = 0x7ffff268fc68 "", m_data_start =
0x7ffff268f898 "\003\060", m_size = 2048, m_writeable = true, m_next = 0x0,
m_free_size = 936, m_read_write_heap = {m_ptr = 0x7fffe401e930}, m_ronly_heap =
{{m_ref_count_ptr = {m_ptr = 0x7fffe401d8e0},
m_heap_start = 0x7ffff1dae000 "GET /test HTTP/1.1\r\nUser-Agent:
curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.14.0.0 zlib/1.2.3
libidn/1.18 libssh2/1.4.2\r\nAccept: */*\r\nHost: localhost.test.url\r\nA:
0123456789ABCDEF012345"..., m_heap_len = 4096, m_locked = false},
{m_ref_count_ptr = {m_ptr = 0x7fffe401d8b0},
m_heap_start = 0x7ffff1dad000
"23456789ABCDEF012345CDE12345678901234567890123456789012345678901234567890123456789012345678912345678912345\r\n\r\n",
m_heap_len = 110, m_locked = false}, {m_ref_count_ptr = {m_ptr =
0x7ffff264f810}, m_heap_start = 0x7ffff264f830 "http8000127.0.0.1", m_heap_len
= 17, m_locked = false}}, m_lost_string_space = 9}
(gdb) p *(HdrStrHeap *)request_url->m_heap->m_read_write_heap
$2 = {<RefCountObj> = {<ForceVFPTToTop> = {_vptr.ForceVFPTToTop = 0x76ccf0},
m_refcount = 1}, m_heap_size = 4096, m_free_start = 0x7fffe401f92c "",
m_free_size = 4}
(gdb) p *(RefCountObj *)request_url->m_heap->m_ronly_heap[0]
$3 = {<ForceVFPTToTop> = {_vptr.ForceVFPTToTop = 0x72ccb0}, m_refcount = 1}
(gdb) b UrlRewrite.cc:309
Breakpoint 2 at 0x5ea8a6: file UrlRewrite.cc, line 309.
(gdb) c
Continuing.
Breakpoint 2, url_rewrite_remap_request (mapping_container=<value optimized
out>, request_url=0x7ffff1d2c128) at UrlRewrite.cc:309
309 Debug("url_rewrite", "%s: Remapping rule id: %d matched", __func__,
mapping_container.getMapping()->map_id);
(gdb) watch *requestPath
Hardware watchpoint 3: *requestPath
(gdb) c
Continuing.
Hardware watchpoint 3: *requestPath
Old value = 116 't'
New value = 0 '\000'
IOBufferData::dealloc (this=0x7fffe401d8e0) at
../../iocore/eventsystem/P_IOBuffer.h:327
327 THREAD_FREE(_data, ioBufAllocator[_size_index], this_thread());
(gdb) bt
#0 IOBufferData::dealloc (this=0x7fffe401d8e0) at
../../iocore/eventsystem/P_IOBuffer.h:327
#1 0x0000000000669969 in IOBufferData::free (this=0x7fffe401d8e0) at
../../iocore/eventsystem/P_IOBuffer.h:340
#2 0x0000000000631a14 in operator= (this=0x7ffff268f810, incoming_size=0) at
../../lib/ts/Ptr.h:412
#3 HdrHeap::coalesce_str_heaps (this=0x7ffff268f810, incoming_size=0) at
HdrHeap.cc:386
#4 0x0000000000631dde in HdrHeap::allocate_str (this=0x7ffff268f810, nbytes=9)
at HdrHeap.cc:289
#5 0x0000000000631ffe in HdrHeap::duplicate_str (this=0x7ffff268f810,
str=0x7fffe401f911 "127.0.0.1localhost.test.url", nbytes=9) at HdrHeap.cc:320
#6 0x0000000000638ca5 in mime_str_u16_set (heap=<value optimized out>,
s_str=<value optimized out>, s_len=9, d_str=0x7ffff268fb48, d_len=<value
optimized out>, must_copy=<value optimized out>) at MIME.cc:2778
#7 0x00000000005ea8d4 in host_set (mapping_container=<value optimized out>,
request_url=0x7ffff1d2c128) at ../../../proxy/hdrs/URL.h:548
#8 url_rewrite_remap_request (mapping_container=<value optimized out>,
request_url=0x7ffff1d2c128) at UrlRewrite.cc:311
#9 0x00000000005f1f45 in RemapPlugins::run_single_remap (this=0x7ffff5cc87f0)
at RemapPlugins.cc:128
#10 0x00000000005e96f8 in RemapProcessor::perform_remap (this=0xa437b0,
cont=0x7ffff1d2ba00, s=0x7ffff1d2ba70) at RemapProcessor.cc:329
#11 0x0000000000591ccd in HttpSM::do_remap_request (this=0x7ffff1d2ba00,
run_inline=true) at HttpSM.cc:3787
#12 0x00000000005a6356 in HttpSM::set_next_state (this=0x7ffff1d2ba00) at
HttpSM.cc:6803
#13 0x00000000005a4772 in HttpSM::handle_api_return (this=0x7ffff1d2ba00) at
HttpSM.cc:1501
#14 0x00000000005a5d6a in HttpSM::set_next_state (this=0x7ffff1d2ba00) at
HttpSM.cc:6790
#15 0x00000000005a4772 in HttpSM::handle_api_return (this=0x7ffff1d2ba00) at
HttpSM.cc:1501
#16 0x00000000005a5d6a in HttpSM::set_next_state (this=0x7ffff1d2ba00) at
HttpSM.cc:6790
#17 0x000000000059b2f6 in HttpSM::state_read_client_request_header
(this=0x7ffff1d2ba00, event=100, data=<value optimized out>) at HttpSM.cc:757
#18 0x00000000005a0ae8 in HttpSM::main_handler (this=0x7ffff1d2ba00, event=100,
data=0x7fffe8015f18) at HttpSM.cc:2482
#19 0x0000000000703a3b in handleEvent (event=<value optimized out>,
vc=0x7fffe8015e10) at ../../iocore/eventsystem/I_Continuation.h:146
#20 read_signal_and_update (event=<value optimized out>, vc=0x7fffe8015e10) at
UnixNetVConnection.cc:216
#21 0x0000000000708191 in read_from_net (nh=0x7ffff5dd2c10, vc=0x7fffe8015e10,
thread=<value optimized out>) at UnixNetVConnection.cc:402
#22 0x00000000006fb932 in NetHandler::mainNetEvent (this=0x7ffff5dd2c10,
event=<value optimized out>, e=<value optimized out>) at UnixNet.cc:399
#23 0x0000000000729a1f in handleEvent (this=0x7ffff5dcf010, e=0x10a9d20,
calling_code=5) at I_Continuation.h:146
#24 EThread::process_event (this=0x7ffff5dcf010, e=0x10a9d20, calling_code=5)
at UnixEThread.cc:145
#25 0x000000000072a3c3 in EThread::execute (this=0x7ffff5dcf010) at
UnixEThread.cc:269
#26 0x0000000000728dca in spawn_thread_internal (a=0x1080560) at Thread.cc:88
#27 0x00007ffff78599d1 in start_thread () from /lib64/libpthread.so.0
#28 0x000000377bee8b6d in clone () from /lib64/libc.so.6
{noformat}
> Large request header causes unexpected remap
> --------------------------------------------
>
> Key: TS-2792
> URL: https://issues.apache.org/jira/browse/TS-2792
> Project: Traffic Server
> Issue Type: Bug
> Affects Versions: 4.0.2, 5.0.0
> Reporter: Masakazu Kitajo
> Fix For: 5.0.0
>
> Attachments: quickfix.diff
>
>
> I get unexpected remap result when I request with likely 4KB of header. It
> seems to be caused by coalescing of heaps.
> In url_rewrite_remap_request, requestPath points to the path string of the
> URL. However, the address of the string may be changed in remap process in
> this function (e.g. request_url->host_set()). Because large header uses lots
> of space so reallocation of heap may be caused when we modify the header
> values. So the memcpy in this function may use the old invalid address as a
> source, and it results unexpected remap and also results broken log outputs.
> It may not cause crashes, but works incorrectly.
> How to reproduce:
> It's hard to reproduce but I believe that requests with likely 3.5 to 4KB of
> header causes this problem.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
