[
https://issues.apache.org/jira/browse/TS-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14036225#comment-14036225
]
Brian Geffon commented on TS-2889:
----------------------------------
[~kichan] your patch will not be sufficient, the underlying issue is that to
maintain backwards compatibility you shouldn't allow dechunking at all.
Additionally, you shouldn't parse the headers when AFTER_BODY is used as the
type. Please try the following patch only:
{code}
Author: Brian Geffon <[email protected]>
Date: Wed Jun 18 12:16:56 2014 -0700
TS-2889: Crash in FetchSM related to spdy FetchSM changes in 5.0.x
diff --git a/proxy/FetchSM.cc b/proxy/FetchSM.cc
index a0a4033..b880a9d 100644
--- a/proxy/FetchSM.cc
+++ b/proxy/FetchSM.cc
@@ -153,7 +153,6 @@ FetchSM::check_chunked()
int ret;
StrList slist;
HTTPHdr *hdr = &client_response_hdr;
-
if (resp_is_chunked >= 0)
return resp_is_chunked;
@@ -310,7 +309,8 @@ FetchSM::get_info_from_buffer(IOBufferReader *the_reader)
info = (char *)ats_malloc(sizeof(char) * (read_avail+1));
client_response = info;
- if (!check_chunked()) {
+ // To maintain backwards compatability we don't allow chunking when it's not
streaming.
+ if (!(fetch_flags & TS_FETCH_FLAGS_STREAM) || !check_chunked()) {
/* Read the data out of the reader */
while (read_avail > 0) {
if (reader->block != NULL)
@@ -373,11 +373,26 @@ FetchSM::process_fetch_read(int event)
Debug(DEBUG_TAG, "[%s] I am here read", __FUNCTION__);
int64_t bytes;
int bytes_used;
+ int64_t total_bytes_copied = 0;
switch (event) {
case TS_EVENT_VCONN_READ_READY:
bytes = resp_reader->read_avail();
Debug(DEBUG_TAG, "[%s] number of bytes in read ready %" PRId64,
__FUNCTION__, bytes);
+
+
+ while (total_bytes_copied < bytes) {
+ int64_t actual_bytes_copied;
+ actual_bytes_copied = resp_buffer->write(resp_reader, bytes, 0);
+ Debug(DEBUG_TAG, "[%s] copied %" PRId64 " bytes", __FUNCTION__,
actual_bytes_copied);
+ if (actual_bytes_copied <= 0) {
+ break;
+ }
+ total_bytes_copied += actual_bytes_copied;
+ }
+ Debug(DEBUG_TAG, "[%s] total copied %" PRId64 " bytes", __FUNCTION__,
total_bytes_copied);
+ resp_reader->consume(total_bytes_copied);
+
if (header_done == 0 && ((fetch_flags & TS_FETCH_FLAGS_STREAM) ||
callback_options == AFTER_HEADER)) {
if (client_response_hdr.parse_resp(&http_parser, resp_reader,
&bytes_used, 0) == PARSE_DONE) {
header_done = 1;
@@ -389,8 +404,6 @@ FetchSM::process_fetch_read(int event)
} else {
if (fetch_flags & TS_FETCH_FLAGS_STREAM)
return InvokePluginExt();
- else
- InvokePlugin(TS_FETCH_EVENT_EXT_BODY_READY, this);
}
read_vio->reenable();
break;
{code}
> Crash in FetchSM related to spdy FetchSM changes in 5.0.x
> ---------------------------------------------------------
>
> Key: TS-2889
> URL: https://issues.apache.org/jira/browse/TS-2889
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, SPDY
> Affects Versions: 5.0.0
> Reporter: Brian Geffon
> Assignee: Brian Geffon
> Fix For: 5.1.0
>
> Attachments: ts2889.diff
>
>
> I'm seeing a crash in the FetchSM on 5.0.x, this is surely because of the
> changes that were made to the FetchSM as a result of SPDY.
> Sample bt:
> #0 0x000000377c632925 in raise () from /lib64/libc.so.6
> #1 0x000000377c634105 in abort () from /lib64/libc.so.6
> #2 0x00002b09b0693ef0 in ink_die_die_die (retval=1) at ink_error.cc:43
> #3 0x00002b09b0693fbd in ink_fatal_va(int, const char *, typedef
> __va_list_tag __va_list_tag *) (return_code=1,
> message_format=0x2b09b06a1358 "%s:%d: failed assert `%s`",
> ap=0x2b09b8806710) at ink_error.cc:65
> #4 0x00002b09b0694086 in ink_fatal (return_code=1,
> message_format=0x2b09b06a1358 "%s:%d: failed assert `%s`")
> at ink_error.cc:73
> #5 0x00002b09b0692d40 in _ink_assert (expression=0x761f2f "header_done",
> file=0x761ede "FetchSM.cc", line=160) at ink_assert.cc:37
> #6 0x00000000004fa5c0 in FetchSM::check_chunked (this=0x2b09f8012240)
> at FetchSM.cc:160
> #7 0x00000000004fac82 in FetchSM::get_info_from_buffer (this=0x2b09f8012240,
> the_reader=0x2b09f4004818) at FetchSM.cc:313
> #8 0x00000000004fb18b in FetchSM::process_fetch_read (this=0x2b09f8012240,
> event=104) at FetchSM.cc:402
> #9 0x00000000004fb42d in FetchSM::fetch_handler (this=0x2b09f8012240,
> event=104, edata=0x2b09f8002768) at FetchSM.cc:449
> #10 0x00000000004fc43e in Continuation::handleEvent (this=0x2b09f8012240,
> event=104, data=0x2b09f8002768)
> at ../iocore/eventsystem/I_Continuation.h:146
> ---Type <return> to continue, or q <return> to quit---
> #11 0x0000000000537f2e in PluginVC::process_read_side (this=0x2b09f8002670,
> other_side_call=false) at PluginVC.cc:637
> #12 0x0000000000536856 in PluginVC::main_handler (this=0x2b09f8002670,
> event=1, data=0x2b0a340293e0) at PluginVC.cc:208
> #13 0x00000000004fc43e in Continuation::handleEvent (this=0x2b09f8002670,
> event=1, data=0x2b0a340293e0) at
> ../iocore/eventsystem/I_Continuation.h:146
> #14 0x000000000075d2e6 in EThread::process_event (this=0x2b09b23cc010,
> e=0x2b0a340293e0, calling_code=1) at UnixEThread.cc:145
> #15 0x000000000075d4b4 in EThread::execute (this=0x2b09b23cc010)
> at UnixEThread.cc:196
> #16 0x000000000075c844 in spawn_thread_internal (a=0x1428b10) at Thread.cc:88
> #17 0x000000377ce079d1 in start_thread () from /lib64/libpthread.so.0
--
This message was sent by Atlassian JIRA
(v6.2#6252)
