[jira] [Commented] (TS-2889) Crash in FetchSM related to spdy FetchSM changes in 5.0.x
[ https://issues.apache.org/jira/browse/TS-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14033504#comment-14033504 ] Kit Chan commented on TS-2889: -- with this change, the crash stops. But I find another problem after that. I call TSFetchUrl with AFTER_BODY as my callback option. The TSFetchUrl/TSFetchRespGet is not working as expected. Previously I can run TSHttpHdrParseResp() against the output of TSFetchRespGet(). With this change, I don't get a TS_PARSE_DONE any more. https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/fetcher/HttpDataFetcherImpl.cc#L164 I think instead we should do this diff --git a/proxy/FetchSM.cc b/proxy/FetchSM.cc index a0a4033..7664e59 100644 --- a/proxy/FetchSM.cc +++ b/proxy/FetchSM.cc @@ -157,7 +157,8 @@ FetchSM::check_chunked() if (resp_is_chunked >= 0) return resp_is_chunked; - ink_release_assert(header_done); + if((fetch_flags & TS_FETCH_FLAGS_STREAM) || callback_options == AFTER_HEADER) +ink_release_assert(header_done); resp_is_chunked = 0; ret = hdr->value_get_comma_list(MIME_FIELD_TRANSFER_ENCODING, > 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 > > > 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 0x00377c632925 in raise () from /lib64/libc.so.6 > #1 0x00377c634105 in abort () from /lib64/libc.so.6 > #2 0x2b09b0693ef0 in ink_die_die_die (retval=1) at ink_error.cc:43 > #3 0x2b09b0693fbd 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 0x2b09b0694086 in ink_fatal (return_code=1, > message_format=0x2b09b06a1358 "%s:%d: failed assert `%s`") > at ink_error.cc:73 > #5 0x2b09b0692d40 in _ink_assert (expression=0x761f2f "header_done", > file=0x761ede "FetchSM.cc", line=160) at ink_assert.cc:37 > #6 0x004fa5c0 in FetchSM::check_chunked (this=0x2b09f8012240) > at FetchSM.cc:160 > #7 0x004fac82 in FetchSM::get_info_from_buffer (this=0x2b09f8012240, > the_reader=0x2b09f4004818) at FetchSM.cc:313 > #8 0x004fb18b in FetchSM::process_fetch_read (this=0x2b09f8012240, > event=104) at FetchSM.cc:402 > #9 0x004fb42d in FetchSM::fetch_handler (this=0x2b09f8012240, > event=104, edata=0x2b09f8002768) at FetchSM.cc:449 > #10 0x004fc43e in Continuation::handleEvent (this=0x2b09f8012240, > event=104, data=0x2b09f8002768) > at ../iocore/eventsystem/I_Continuation.h:146 > ---Type to continue, or q to quit--- > #11 0x00537f2e in PluginVC::process_read_side (this=0x2b09f8002670, > other_side_call=false) at PluginVC.cc:637 > #12 0x00536856 in PluginVC::main_handler (this=0x2b09f8002670, > event=1, data=0x2b0a340293e0) at PluginVC.cc:208 > #13 0x004fc43e in Continuation::handleEvent (this=0x2b09f8002670, > event=1, data=0x2b0a340293e0) at > ../iocore/eventsystem/I_Continuation.h:146 > #14 0x0075d2e6 in EThread::process_event (this=0x2b09b23cc010, > e=0x2b0a340293e0, calling_code=1) at UnixEThread.cc:145 > #15 0x0075d4b4 in EThread::execute (this=0x2b09b23cc010) > at UnixEThread.cc:196 > #16 0x0075c844 in spawn_thread_internal (a=0x1428b10) at Thread.cc:88 > #17 0x00377ce079d1 in start_thread () from /lib64/libpthread.so.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (TS-2889) Crash in FetchSM related to spdy FetchSM changes in 5.0.x
[ https://issues.apache.org/jira/browse/TS-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14033504#comment-14033504 ] Kit Chan edited comment on TS-2889 at 6/17/14 7:12 AM: --- with this change, the crash stops. But I find another problem after that. I call TSFetchUrl with AFTER_BODY as my callback option. The TSFetchUrl/TSFetchRespGet is not working as expected. Previously I can run TSHttpHdrParseResp() against the output of TSFetchRespGet(). With this change, I don't get a TS_PARSE_DONE any more. https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/fetcher/HttpDataFetcherImpl.cc#L164 I think instead patching it differently was (Author: kichan): with this change, the crash stops. But I find another problem after that. I call TSFetchUrl with AFTER_BODY as my callback option. The TSFetchUrl/TSFetchRespGet is not working as expected. Previously I can run TSHttpHdrParseResp() against the output of TSFetchRespGet(). With this change, I don't get a TS_PARSE_DONE any more. https://github.com/apache/trafficserver/blob/master/plugins/experimental/esi/fetcher/HttpDataFetcherImpl.cc#L164 I think instead we should do this diff --git a/proxy/FetchSM.cc b/proxy/FetchSM.cc index a0a4033..7664e59 100644 --- a/proxy/FetchSM.cc +++ b/proxy/FetchSM.cc @@ -157,7 +157,8 @@ FetchSM::check_chunked() if (resp_is_chunked >= 0) return resp_is_chunked; - ink_release_assert(header_done); + if((fetch_flags & TS_FETCH_FLAGS_STREAM) || callback_options == AFTER_HEADER) +ink_release_assert(header_done); resp_is_chunked = 0; ret = hdr->value_get_comma_list(MIME_FIELD_TRANSFER_ENCODING, > 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 > > > 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 0x00377c632925 in raise () from /lib64/libc.so.6 > #1 0x00377c634105 in abort () from /lib64/libc.so.6 > #2 0x2b09b0693ef0 in ink_die_die_die (retval=1) at ink_error.cc:43 > #3 0x2b09b0693fbd 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 0x2b09b0694086 in ink_fatal (return_code=1, > message_format=0x2b09b06a1358 "%s:%d: failed assert `%s`") > at ink_error.cc:73 > #5 0x2b09b0692d40 in _ink_assert (expression=0x761f2f "header_done", > file=0x761ede "FetchSM.cc", line=160) at ink_assert.cc:37 > #6 0x004fa5c0 in FetchSM::check_chunked (this=0x2b09f8012240) > at FetchSM.cc:160 > #7 0x004fac82 in FetchSM::get_info_from_buffer (this=0x2b09f8012240, > the_reader=0x2b09f4004818) at FetchSM.cc:313 > #8 0x004fb18b in FetchSM::process_fetch_read (this=0x2b09f8012240, > event=104) at FetchSM.cc:402 > #9 0x004fb42d in FetchSM::fetch_handler (this=0x2b09f8012240, > event=104, edata=0x2b09f8002768) at FetchSM.cc:449 > #10 0x004fc43e in Continuation::handleEvent (this=0x2b09f8012240, > event=104, data=0x2b09f8002768) > at ../iocore/eventsystem/I_Continuation.h:146 > ---Type to continue, or q to quit--- > #11 0x00537f2e in PluginVC::process_read_side (this=0x2b09f8002670, > other_side_call=false) at PluginVC.cc:637 > #12 0x00536856 in PluginVC::main_handler (this=0x2b09f8002670, > event=1, data=0x2b0a340293e0) at PluginVC.cc:208 > #13 0x004fc43e in Continuation::handleEvent (this=0x2b09f8002670, > event=1, data=0x2b0a340293e0) at > ../iocore/eventsystem/I_Continuation.h:146 > #14 0x0075d2e6 in EThread::process_event (this=0x2b09b23cc010, > e=0x2b0a340293e0, calling_code=1) at UnixEThread.cc:145 > #15 0x0075d4b4 in EThread::execute (this=0x2b09b23cc010) > at UnixEThread.cc:196 > #16 0x0075c844 in spawn_thread_internal (a=0x1428b10) at Thread.cc:88 > #17 0x00377ce079d1 in start_thread () from /lib64/libpthread.so.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2889) Crash in FetchSM related to spdy FetchSM changes in 5.0.x
[ https://issues.apache.org/jira/browse/TS-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kit Chan updated TS-2889: - Attachment: ts2889.diff This is my patch. I think instead we should check the right condition for doing the assertion. > 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 0x00377c632925 in raise () from /lib64/libc.so.6 > #1 0x00377c634105 in abort () from /lib64/libc.so.6 > #2 0x2b09b0693ef0 in ink_die_die_die (retval=1) at ink_error.cc:43 > #3 0x2b09b0693fbd 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 0x2b09b0694086 in ink_fatal (return_code=1, > message_format=0x2b09b06a1358 "%s:%d: failed assert `%s`") > at ink_error.cc:73 > #5 0x2b09b0692d40 in _ink_assert (expression=0x761f2f "header_done", > file=0x761ede "FetchSM.cc", line=160) at ink_assert.cc:37 > #6 0x004fa5c0 in FetchSM::check_chunked (this=0x2b09f8012240) > at FetchSM.cc:160 > #7 0x004fac82 in FetchSM::get_info_from_buffer (this=0x2b09f8012240, > the_reader=0x2b09f4004818) at FetchSM.cc:313 > #8 0x004fb18b in FetchSM::process_fetch_read (this=0x2b09f8012240, > event=104) at FetchSM.cc:402 > #9 0x004fb42d in FetchSM::fetch_handler (this=0x2b09f8012240, > event=104, edata=0x2b09f8002768) at FetchSM.cc:449 > #10 0x004fc43e in Continuation::handleEvent (this=0x2b09f8012240, > event=104, data=0x2b09f8002768) > at ../iocore/eventsystem/I_Continuation.h:146 > ---Type to continue, or q to quit--- > #11 0x00537f2e in PluginVC::process_read_side (this=0x2b09f8002670, > other_side_call=false) at PluginVC.cc:637 > #12 0x00536856 in PluginVC::main_handler (this=0x2b09f8002670, > event=1, data=0x2b0a340293e0) at PluginVC.cc:208 > #13 0x004fc43e in Continuation::handleEvent (this=0x2b09f8002670, > event=1, data=0x2b0a340293e0) at > ../iocore/eventsystem/I_Continuation.h:146 > #14 0x0075d2e6 in EThread::process_event (this=0x2b09b23cc010, > e=0x2b0a340293e0, calling_code=1) at UnixEThread.cc:145 > #15 0x0075d4b4 in EThread::execute (this=0x2b09b23cc010) > at UnixEThread.cc:196 > #16 0x0075c844 in spawn_thread_internal (a=0x1428b10) at Thread.cc:88 > #17 0x00377ce079d1 in start_thread () from /lib64/libpthread.so.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2883) core dump in TSFetchCreate()
[
https://issues.apache.org/jira/browse/TS-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2883:
--
Attachment: (was: ts2883.diff)
> core dump in TSFetchCreate()
>
>
> Key: TS-2883
> URL: https://issues.apache.org/jira/browse/TS-2883
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, SPDY
>Reporter: Sudheer Vinukonda
> Attachments: ts2883.diff
>
>
> {code}
> (gdb) bt
> #0 ink_freelist_new (f=0x2923050) at ink_queue.cc:202
> #1 0x004c0cd2 in alloc (contp=0x2b86821e2120,
> method=TS_FETCH_METHOD_POST,
> url=0x2b865d64f228
> "https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeo&m=BatchExecute&wssid=nG7kmTWsJCD&action=compose_0_savedraft&actionCount=88&debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8&deb";...,
> version=0x2b865da5ace8 "HTTP/1.1", client_addr=,
> flags=) at ../lib/ts/Allocator.h:117
> #2 TSFetchCreate (contp=0x2b86821e2120, method=TS_FETCH_METHOD_POST,
> url=0x2b865d64f228
> "https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeo&m=BatchExecute&wssid=nG7kmTWsJCD&action=compose_0_savedraft&actionCount=88&debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8&deb";...,
> version=0x2b865da5ace8 "HTTP/1.1", client_addr=,
> flags=) at InkAPI.cc:7289
> #3 0x005f117e in spdy_fetcher_launch (req=0x2b871c2fa900,
> method=TS_FETCH_METHOD_POST) at SpdyCallbacks.cc:187
> #4 0x005f1faa in spdy_process_syn_stream_frame (session= optimized out>, type=, frame=,
> user_data=0x2b86821e2120)
> at SpdyCallbacks.cc:295
> #5 spdy_on_ctrl_recv_callback (session=, type= optimized out>, frame=, user_data=0x2b86821e2120) at
> SpdyCallbacks.cc:335
> #6 0x00738050 in spdylay_session_on_syn_stream_received
> (session=0x2b865defce10, frame=0x2b858f987a20) at spdylay_session.c:1782
> #7 0x00738d57 in spdylay_session_process_ctrl_frame
> (session=0x2b865defce10, in=0x2b858f987a90 "\200\003", inlen= out>) at spdylay_session.c:2246
> #8 spdylay_session_mem_recv (session=0x2b865defce10, in=0x2b858f987a90
> "\200\003", inlen=) at spdylay_session.c:2805
> #9 0x00738f89 in spdylay_session_recv (session=0x2b865defce10) at
> spdylay_session.c:2828
> #10 0x005ef17b in spdy_process_read (this=0x2b86821e2120, event=100,
> edata=) at SpdyClientSession.cc:279
> #11 SpdyClientSession::state_session_readwrite (this=0x2b86821e2120,
> event=100, edata=) at SpdyClientSession.cc:236
> #12 0x0070dbd7 in handleEvent (this=0x2b86fc1d2cf0, event= optimized out>) at ../../iocore/eventsystem/I_Continuation.h:146
> #13 read_signal_and_update (this=0x2b86fc1d2cf0, event=)
> at UnixNetVConnection.cc:138
> #14 UnixNetVConnection::readSignalAndUpdate (this=0x2b86fc1d2cf0,
> event=) at UnixNetVConnection.cc:914
> #15 0x006fe66f in SSLNetVConnection::net_read_io
> (this=0x2b86fc1d2cf0, nh=0x2b858d46bbf0, lthread=0x2b858d468010) at
> SSLNetVConnection.cc:294
> #16 0x00705a72 in NetHandler::mainNetEvent (this=0x2b858d46bbf0,
> event=, e=) at UnixNet.cc:399
> #17 0x007323ef in handleEvent (this=0x2b858d468010, e=0x2a7db30,
> calling_code=5) at I_Continuation.h:146
> #18 EThread::process_event (this=0x2b858d468010, e=0x2a7db30, calling_code=5)
> at UnixEThread.cc:145
> #19 0x00732d93 in EThread::execute (this=0x2b858d468010) at
> UnixEThread.cc:269
> #20 0x0073179a in spawn_thread_internal (a=0x2e404e0) at Thread.cc:88
> #21 0x2b835bf28851 in start_thread () from /lib64/libpthread.so.0
> #22 0x00361a0e894d in clone () from /lib64/libc.so.6
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2883) core dump in TSFetchCreate()
[
https://issues.apache.org/jira/browse/TS-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14033919#comment-14033919
]
Sudheer Vinukonda commented on TS-2883:
---
No cores so far with this fix. Enhanced the patch slightly with additional
protection per Wei Sun's suggestion, to destroy fetch_sm when there's a fetch
error.
{code}
diff --git a/proxy/spdy/SpdyClientSession.cc b/proxy/spdy/SpdyClientSession.cc
index 8ea8072..9ea7680 100644
--- a/proxy/spdy/SpdyClientSession.cc
+++ b/proxy/spdy/SpdyClientSession.cc
@@ -336,16 +336,21 @@ spdy_process_fetch(TSEvent event, SpdyClientSession *sm,
void *edata)
Debug("spdy", "[FETCH ERROR]");
if (req->fetch_body_completed)
ret = 0; // Ignore fetch errors after FETCH BODY DONE
-else
+else {
+ Error("spdy_process_fetch fetch error, ret %d for sm_id %u, stream_id
%u, req time %lld, url %s", ret, sm->sm_id, req->stream_id, req->start_time,
req->url.c_str());
+ TSFetchDestroy(req->fetch_sm);
req->fetch_sm = NULL;
+}
break;
{code}
> core dump in TSFetchCreate()
>
>
> Key: TS-2883
> URL: https://issues.apache.org/jira/browse/TS-2883
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, SPDY
>Reporter: Sudheer Vinukonda
> Attachments: ts2883.diff
>
>
> {code}
> (gdb) bt
> #0 ink_freelist_new (f=0x2923050) at ink_queue.cc:202
> #1 0x004c0cd2 in alloc (contp=0x2b86821e2120,
> method=TS_FETCH_METHOD_POST,
> url=0x2b865d64f228
> "https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeo&m=BatchExecute&wssid=nG7kmTWsJCD&action=compose_0_savedraft&actionCount=88&debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8&deb";...,
> version=0x2b865da5ace8 "HTTP/1.1", client_addr=,
> flags=) at ../lib/ts/Allocator.h:117
> #2 TSFetchCreate (contp=0x2b86821e2120, method=TS_FETCH_METHOD_POST,
> url=0x2b865d64f228
> "https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeo&m=BatchExecute&wssid=nG7kmTWsJCD&action=compose_0_savedraft&actionCount=88&debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8&deb";...,
> version=0x2b865da5ace8 "HTTP/1.1", client_addr=,
> flags=) at InkAPI.cc:7289
> #3 0x005f117e in spdy_fetcher_launch (req=0x2b871c2fa900,
> method=TS_FETCH_METHOD_POST) at SpdyCallbacks.cc:187
> #4 0x005f1faa in spdy_process_syn_stream_frame (session= optimized out>, type=, frame=,
> user_data=0x2b86821e2120)
> at SpdyCallbacks.cc:295
> #5 spdy_on_ctrl_recv_callback (session=, type= optimized out>, frame=, user_data=0x2b86821e2120) at
> SpdyCallbacks.cc:335
> #6 0x00738050 in spdylay_session_on_syn_stream_received
> (session=0x2b865defce10, frame=0x2b858f987a20) at spdylay_session.c:1782
> #7 0x00738d57 in spdylay_session_process_ctrl_frame
> (session=0x2b865defce10, in=0x2b858f987a90 "\200\003", inlen= out>) at spdylay_session.c:2246
> #8 spdylay_session_mem_recv (session=0x2b865defce10, in=0x2b858f987a90
> "\200\003", inlen=) at spdylay_session.c:2805
> #9 0x00738f89 in spdylay_session_recv (session=0x2b865defce10) at
> spdylay_session.c:2828
> #10 0x005ef17b in spdy_process_read (this=0x2b86821e2120, event=100,
> edata=) at SpdyClientSession.cc:279
> #11 SpdyClientSession::state_session_readwrite (this=0x2b86821e2120,
> event=100, edata=) at SpdyClientSession.cc:236
> #12 0x0070dbd7 in handleEvent (this=0x2b86fc1d2cf0, event= optimized out>) at ../../iocore/eventsystem/I_Continuation.h:146
> #13 read_signal_and_update (this=0x2b86fc1d2cf0, event=)
> at UnixNetVConnection.cc:138
> #14 UnixNetVConnection::readSignalAndUpdate (this=0x2b86fc1d2cf0,
> event=) at UnixNetVConnection.cc:914
> #15 0x006fe66f in SSLNetVConnection::net_read_io
> (this=0x2b86fc1d2cf0, nh=0x2b858d46bbf0, lthread=0x2b858d468010) at
> SSLNetVConnection.cc:294
> #16 0x00705a72 in NetHandler::mainNetEvent (this=0x2b858d46bbf0,
> event=, e=) at UnixNet.cc:399
> #17 0x007323ef in handleEvent (this=0x2b858d468010, e=0x2a7db30,
> calling_code=5) at I_Continuation.h:146
> #18 EThread::process_event (this=0x2b858d468010, e=0x2a7db30, calling_code=5)
> at UnixEThread.cc:145
> #19 0x00732d93 in EThread::execute (this=0x2b858d468010) at
> UnixEThread.cc:269
> #20 0x0073179a in spawn_thread_internal (a=0x2e404e0) at Thread.cc:88
> #21 0x2b835bf28851 in start_thread () from /lib64/libpthread.so.0
> #22 0x00361a0e894d in clone () from /lib64/libc.so.6
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2882) Core dump in handlEvent in handling event VC_EVENT_INACTIVITY_TIMEOUT
[
https://issues.apache.org/jira/browse/TS-2882?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14033923#comment-14033923
]
Sudheer Vinukonda commented on TS-2882:
---
No cores since the fix attached in TS-2883 was applied. Will monitor further,
but, if this doesn't happen before tomorrow, it may be closed as duplicate of
TS-2883
> Core dump in handlEvent in handling event VC_EVENT_INACTIVITY_TIMEOUT
> -
>
> Key: TS-2882
> URL: https://issues.apache.org/jira/browse/TS-2882
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, SPDY
>Reporter: Sudheer Vinukonda
>
> {code}
> (gdb)
> #0 0x0070f3f7 in handleEvent (event=105, vc=0x2b5f1c27baf0) at
> ../../iocore/eventsystem/I_Continuation.h:146
> #1 read_signal_and_update (event=105, vc=0x2b5f1c27baf0) at
> UnixNetVConnection.cc:138
> #2 0x0071381f in UnixNetVConnection::mainEvent (this=0x2b5f1c27baf0,
> event=, e=) at
> UnixNetVConnection.cc:1066
> #3 0x007080c5 in handleEvent (this=0x1bd9130, event= out>, e=0x13888d0) at ../../iocore/eventsystem/I_Continuation.h:146
> #4 InactivityCop::check_inactivity (this=0x1bd9130, event= out>, e=0x13888d0) at UnixNet.cc:80
> #5 0x0073409f in handleEvent (this=0x2b5ec2eb2010, e=0x13888d0,
> calling_code=2) at I_Continuation.h:146
> #6 EThread::process_event (this=0x2b5ec2eb2010, e=0x13888d0, calling_code=2)
> at UnixEThread.cc:145
> #7 0x00734c13 in EThread::execute (this=0x2b5ec2eb2010) at
> UnixEThread.cc:224
> #8 0x0073344a in spawn_thread_internal (a=0x174b830) at Thread.cc:88
> #9 0x2b5c8b3de851 in start_thread () from /lib64/libpthread.so.0
> #10 0x00366a4e894d in clone () from /lib64/libc.so.6
> (gdb) frame 0
> #0 0x0070f3f7 in handleEvent (event=105, vc=0x2b5f1c27baf0) at
> ../../iocore/eventsystem/I_Continuation.h:146
> 146 return (this->*handler) (event, data);
> (gdb) print this
> $6 = (Continuation * const) 0x2b6196ab9f40
> (gdb) print *this
> $7 = { = {_vptr.force_VFPT_to_top = 0x15}, handler =
> &virtual table offset 20, this adjustment 1, mutex = {m_ptr =
> 0x6d2e35676d2d7375}, link = {> = {
> next = 0x6f6861792e6c6961}, prev = 0x6d6f632e6f}}
> (gdb) print this->handler
> $8 = &virtual table offset 20, this adjustment 1
> (gdb) print this->*handler
> Cannot access memory at address 0x1510
> (gdb) print event
> $9 = 105
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2890) Core dump in spdylay_submit_syn_reply
[
https://issues.apache.org/jira/browse/TS-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14033924#comment-14033924
]
Sudheer Vinukonda commented on TS-2890:
---
Disabled spdy for http ports, since, we don't intend to use spdy on http ports.
Since, then, this core has not occured.
> Core dump in spdylay_submit_syn_reply
> -
>
> Key: TS-2890
> URL: https://issues.apache.org/jira/browse/TS-2890
> Project: Traffic Server
> Issue Type: Bug
> Components: SPDY
>Reporter: Sudheer Vinukonda
>
> session object seems to be fine in spdy_process_fetch_header(), but, is null
> inside spdylay_submit_syn_reply() resulting in a crash. Based on the stack
> trace, this looks to be spdy connection on http port.
> {code}
> #0 spdylay_submit_syn_reply (session=0x0, flags=0 '\000', stream_id=33,
> nv=0x2ba4dc1d9c90) at spdylay_submit.c:137
> #1 0x005ef804 in spdy_process_fetch_header (this=0x2ba62cbdc880,
> event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:366
> #2 spdy_process_fetch (this=0x2ba62cbdc880, event=-2, edata=0x2ba68aa47a60)
> at SpdyClientSession.cc:321
> #3 SpdyClientSession::state_session_readwrite (this=0x2ba62cbdc880,
> event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:251
> #4 0x004a46da in handleEvent (this=0x2ba68aa47a60, error_event=0) at
> ../iocore/eventsystem/I_Continuation.h:146
> #5 FetchSM::InvokePluginExt (this=0x2ba68aa47a60, error_event=0) at
> FetchSM.cc:233
> #6 0x004a4bb7 in FetchSM::process_fetch_read (this=0x2ba68aa47a60,
> event=) at FetchSM.cc:400
> #7 0x004a4d6b in FetchSM::fetch_handler (this=0x2ba68aa47a60,
> event=104, edata=0x2ba670cf8a18) at FetchSM.cc:449
> #8 0x004dd82a in PluginVC::process_read_side (this=0x2ba670cf8920,
> other_side_call=false) at PluginVC.cc:637
> #9 0x004df81a in PluginVC::main_handler (this=0x2ba670cf8920,
> event=, data=0x2ba539202740) at PluginVC.cc:208
> #10 0x0073409f in handleEvent (this=0x2ba3b2323010, e=0x2ba539202740,
> calling_code=1) at I_Continuation.h:146
> #11 EThread::process_event (this=0x2ba3b2323010, e=0x2ba539202740,
> calling_code=1) at UnixEThread.cc:145
> #12 0x00734c73 in EThread::execute (this=0x2ba3b2323010) at
> UnixEThread.cc:239
> #13 0x0073344a in spawn_thread_internal (a=0x2645060) at Thread.cc:88
> #14 0x2ba3aaf15851 in start_thread () from /lib64/libpthread.so.0
> #15 0x0038818e894d in clone () from /lib64/libc.so.6
> (gdb) print session
> $36 = (spdylay_session *) 0x0
> (gdb) up
> #1 0x005ef804 in spdy_process_fetch_header (this=0x2ba62cbdc880,
> event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:366
> 366 SpdyClientSession.cc: No such file or directory.
> in SpdyClientSession.cc
> (gdb) print sm->session
> $37 = (spdylay_session *) 0x2ba56ad12130
> (gdb) print *sm->session
> $38 = {streams = {table = 0x2ba5689b86d0, tablelen = 16, size = 0}, ob_pq =
> {q = 0x2ba56989df50, length = 0, capacity = 4096, compar = 0x736a50
> }, ob_ss_pq = {
> q = 0x2ba5681edfd0, length = 0, capacity = 4096, compar = 0x736a50
> }, aob = {item = 0x0, framebuf = 0x2ba64d7e4be0
> "\200\003", framebufmax = 4104,
> framebuflen = 0, framebufoff = 0}, iframe = {inflatebuf = {capacity =
> 4096, root = {data = 0x0, next = 0x0}, current = 0x2ba56ad121b8, len = 0,
> last_offset = 4096},
> buf = 0x2ba56913a3c0 "\300\235'k\245+", headbufoff = 0, bufmax = 4104,
> buflen = 0, payloadlen = 0, off = 0, state = SPDYLAY_RECV_HEAD, error_code =
> 0,
> headbuf = "\000\000\000\000\000\000\000"}, hd_deflater = {zst = {next_in
> = 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out =
> 0, msg = 0x0,
> state = 0x2ba64f2b6900, zalloc = 0x3882408da0 , zfree =
> 0x3882408d90 , opaque = 0x0, data_type = 2, adler = 3821447106,
> reserved = 0}, version = 3}, hd_inflater = {
> zst = {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0,
> avail_out = 0, total_out = 0, msg = 0x0, state = 0x2ba64cb426e0, zalloc =
> 0x3882408da0 ,
> zfree = 0x3882408d90 , opaque = 0x0, data_type = 0, adler = 1,
> reserved = 0}, version = 3}, cli_certvec = {vector = 0x0, size = 0, capacity
> = 0, last_slot = 0}, callbacks = {
> send_callback = 0x5f15b0 const*, size_t, int, void*)>,
> recv_callback = 0x5f14f0 size_t, int, void*)>,
> on_ctrl_recv_callback = 0x5f1fc0
> spdylay_frame*, void*)>,
> on_invalid_ctrl_recv_callback = 0x5f1000
> spdylay_frame*, uint32_t, void*)>,
> on_data_chunk_recv_callback = 0x5f1ce0
> const*, size_t, void*)>,
> on_data_recv_callback = 0x5f1ad0
> void*)>,
> before_ctrl_send_callback = 0x5f1010
> spdylay_frame*, void*)>,
> on_ctrl_send_callback = 0x5f14d0
> spdylay_frame*, void*)>,
> on_ctrl_not_send_call
[jira] [Comment Edited] (TS-2890) Core dump in spdylay_submit_syn_reply
[
https://issues.apache.org/jira/browse/TS-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14033924#comment-14033924
]
Sudheer Vinukonda edited comment on TS-2890 at 6/17/14 3:29 PM:
Disabled spdy for http ports, since, we don't intend to use spdy on http ports.
Since, then, this core has not occurred.
was (Author: sudheerv):
Disabled spdy for http ports, since, we don't intend to use spdy on http ports.
Since, then, this core has not occured.
> Core dump in spdylay_submit_syn_reply
> -
>
> Key: TS-2890
> URL: https://issues.apache.org/jira/browse/TS-2890
> Project: Traffic Server
> Issue Type: Bug
> Components: SPDY
>Reporter: Sudheer Vinukonda
>
> session object seems to be fine in spdy_process_fetch_header(), but, is null
> inside spdylay_submit_syn_reply() resulting in a crash. Based on the stack
> trace, this looks to be spdy connection on http port.
> {code}
> #0 spdylay_submit_syn_reply (session=0x0, flags=0 '\000', stream_id=33,
> nv=0x2ba4dc1d9c90) at spdylay_submit.c:137
> #1 0x005ef804 in spdy_process_fetch_header (this=0x2ba62cbdc880,
> event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:366
> #2 spdy_process_fetch (this=0x2ba62cbdc880, event=-2, edata=0x2ba68aa47a60)
> at SpdyClientSession.cc:321
> #3 SpdyClientSession::state_session_readwrite (this=0x2ba62cbdc880,
> event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:251
> #4 0x004a46da in handleEvent (this=0x2ba68aa47a60, error_event=0) at
> ../iocore/eventsystem/I_Continuation.h:146
> #5 FetchSM::InvokePluginExt (this=0x2ba68aa47a60, error_event=0) at
> FetchSM.cc:233
> #6 0x004a4bb7 in FetchSM::process_fetch_read (this=0x2ba68aa47a60,
> event=) at FetchSM.cc:400
> #7 0x004a4d6b in FetchSM::fetch_handler (this=0x2ba68aa47a60,
> event=104, edata=0x2ba670cf8a18) at FetchSM.cc:449
> #8 0x004dd82a in PluginVC::process_read_side (this=0x2ba670cf8920,
> other_side_call=false) at PluginVC.cc:637
> #9 0x004df81a in PluginVC::main_handler (this=0x2ba670cf8920,
> event=, data=0x2ba539202740) at PluginVC.cc:208
> #10 0x0073409f in handleEvent (this=0x2ba3b2323010, e=0x2ba539202740,
> calling_code=1) at I_Continuation.h:146
> #11 EThread::process_event (this=0x2ba3b2323010, e=0x2ba539202740,
> calling_code=1) at UnixEThread.cc:145
> #12 0x00734c73 in EThread::execute (this=0x2ba3b2323010) at
> UnixEThread.cc:239
> #13 0x0073344a in spawn_thread_internal (a=0x2645060) at Thread.cc:88
> #14 0x2ba3aaf15851 in start_thread () from /lib64/libpthread.so.0
> #15 0x0038818e894d in clone () from /lib64/libc.so.6
> (gdb) print session
> $36 = (spdylay_session *) 0x0
> (gdb) up
> #1 0x005ef804 in spdy_process_fetch_header (this=0x2ba62cbdc880,
> event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:366
> 366 SpdyClientSession.cc: No such file or directory.
> in SpdyClientSession.cc
> (gdb) print sm->session
> $37 = (spdylay_session *) 0x2ba56ad12130
> (gdb) print *sm->session
> $38 = {streams = {table = 0x2ba5689b86d0, tablelen = 16, size = 0}, ob_pq =
> {q = 0x2ba56989df50, length = 0, capacity = 4096, compar = 0x736a50
> }, ob_ss_pq = {
> q = 0x2ba5681edfd0, length = 0, capacity = 4096, compar = 0x736a50
> }, aob = {item = 0x0, framebuf = 0x2ba64d7e4be0
> "\200\003", framebufmax = 4104,
> framebuflen = 0, framebufoff = 0}, iframe = {inflatebuf = {capacity =
> 4096, root = {data = 0x0, next = 0x0}, current = 0x2ba56ad121b8, len = 0,
> last_offset = 4096},
> buf = 0x2ba56913a3c0 "\300\235'k\245+", headbufoff = 0, bufmax = 4104,
> buflen = 0, payloadlen = 0, off = 0, state = SPDYLAY_RECV_HEAD, error_code =
> 0,
> headbuf = "\000\000\000\000\000\000\000"}, hd_deflater = {zst = {next_in
> = 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out =
> 0, msg = 0x0,
> state = 0x2ba64f2b6900, zalloc = 0x3882408da0 , zfree =
> 0x3882408d90 , opaque = 0x0, data_type = 2, adler = 3821447106,
> reserved = 0}, version = 3}, hd_inflater = {
> zst = {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0,
> avail_out = 0, total_out = 0, msg = 0x0, state = 0x2ba64cb426e0, zalloc =
> 0x3882408da0 ,
> zfree = 0x3882408d90 , opaque = 0x0, data_type = 0, adler = 1,
> reserved = 0}, version = 3}, cli_certvec = {vector = 0x0, size = 0, capacity
> = 0, last_slot = 0}, callbacks = {
> send_callback = 0x5f15b0 const*, size_t, int, void*)>,
> recv_callback = 0x5f14f0 size_t, int, void*)>,
> on_ctrl_recv_callback = 0x5f1fc0
> spdylay_frame*, void*)>,
> on_invalid_ctrl_recv_callback = 0x5f1000
> spdylay_frame*, uint32_t, void*)>,
> on_data_chunk_recv_callback = 0x5f1ce0
> const*, size_t, void*)>,
> on_data_recv_callb
[jira] [Updated] (TS-2883) core dump in TSFetchCreate()
[
https://issues.apache.org/jira/browse/TS-2883?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-2883:
--
Attachment: ts2883.diff
> core dump in TSFetchCreate()
>
>
> Key: TS-2883
> URL: https://issues.apache.org/jira/browse/TS-2883
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, SPDY
>Reporter: Sudheer Vinukonda
> Attachments: ts2883.diff
>
>
> {code}
> (gdb) bt
> #0 ink_freelist_new (f=0x2923050) at ink_queue.cc:202
> #1 0x004c0cd2 in alloc (contp=0x2b86821e2120,
> method=TS_FETCH_METHOD_POST,
> url=0x2b865d64f228
> "https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeo&m=BatchExecute&wssid=nG7kmTWsJCD&action=compose_0_savedraft&actionCount=88&debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8&deb";...,
> version=0x2b865da5ace8 "HTTP/1.1", client_addr=,
> flags=) at ../lib/ts/Allocator.h:117
> #2 TSFetchCreate (contp=0x2b86821e2120, method=TS_FETCH_METHOD_POST,
> url=0x2b865d64f228
> "https://aa-mg5.mail.yahoo.com/ws/mail/v2.0/jsonrpc?appid=YahooMailNeo&m=BatchExecute&wssid=nG7kmTWsJCD&action=compose_0_savedraft&actionCount=88&debugmid=2_0_0_3_126623_AMNwimIAAC82U5ZXLwAAAFWGrR8&deb";...,
> version=0x2b865da5ace8 "HTTP/1.1", client_addr=,
> flags=) at InkAPI.cc:7289
> #3 0x005f117e in spdy_fetcher_launch (req=0x2b871c2fa900,
> method=TS_FETCH_METHOD_POST) at SpdyCallbacks.cc:187
> #4 0x005f1faa in spdy_process_syn_stream_frame (session= optimized out>, type=, frame=,
> user_data=0x2b86821e2120)
> at SpdyCallbacks.cc:295
> #5 spdy_on_ctrl_recv_callback (session=, type= optimized out>, frame=, user_data=0x2b86821e2120) at
> SpdyCallbacks.cc:335
> #6 0x00738050 in spdylay_session_on_syn_stream_received
> (session=0x2b865defce10, frame=0x2b858f987a20) at spdylay_session.c:1782
> #7 0x00738d57 in spdylay_session_process_ctrl_frame
> (session=0x2b865defce10, in=0x2b858f987a90 "\200\003", inlen= out>) at spdylay_session.c:2246
> #8 spdylay_session_mem_recv (session=0x2b865defce10, in=0x2b858f987a90
> "\200\003", inlen=) at spdylay_session.c:2805
> #9 0x00738f89 in spdylay_session_recv (session=0x2b865defce10) at
> spdylay_session.c:2828
> #10 0x005ef17b in spdy_process_read (this=0x2b86821e2120, event=100,
> edata=) at SpdyClientSession.cc:279
> #11 SpdyClientSession::state_session_readwrite (this=0x2b86821e2120,
> event=100, edata=) at SpdyClientSession.cc:236
> #12 0x0070dbd7 in handleEvent (this=0x2b86fc1d2cf0, event= optimized out>) at ../../iocore/eventsystem/I_Continuation.h:146
> #13 read_signal_and_update (this=0x2b86fc1d2cf0, event=)
> at UnixNetVConnection.cc:138
> #14 UnixNetVConnection::readSignalAndUpdate (this=0x2b86fc1d2cf0,
> event=) at UnixNetVConnection.cc:914
> #15 0x006fe66f in SSLNetVConnection::net_read_io
> (this=0x2b86fc1d2cf0, nh=0x2b858d46bbf0, lthread=0x2b858d468010) at
> SSLNetVConnection.cc:294
> #16 0x00705a72 in NetHandler::mainNetEvent (this=0x2b858d46bbf0,
> event=, e=) at UnixNet.cc:399
> #17 0x007323ef in handleEvent (this=0x2b858d468010, e=0x2a7db30,
> calling_code=5) at I_Continuation.h:146
> #18 EThread::process_event (this=0x2b858d468010, e=0x2a7db30, calling_code=5)
> at UnixEThread.cc:145
> #19 0x00732d93 in EThread::execute (this=0x2b858d468010) at
> UnixEThread.cc:269
> #20 0x0073179a in spawn_thread_internal (a=0x2e404e0) at Thread.cc:88
> #21 0x2b835bf28851 in start_thread () from /lib64/libpthread.so.0
> #22 0x00361a0e894d in clone () from /lib64/libc.so.6
> {code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2890) Core dump in spdylay_submit_syn_reply
[
https://issues.apache.org/jira/browse/TS-2890?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-2890:
--
Fix Version/s: 5.1.0
> Core dump in spdylay_submit_syn_reply
> -
>
> Key: TS-2890
> URL: https://issues.apache.org/jira/browse/TS-2890
> Project: Traffic Server
> Issue Type: Bug
> Components: SPDY
>Reporter: Sudheer Vinukonda
> Fix For: 5.1.0
>
>
> session object seems to be fine in spdy_process_fetch_header(), but, is null
> inside spdylay_submit_syn_reply() resulting in a crash. Based on the stack
> trace, this looks to be spdy connection on http port.
> {code}
> #0 spdylay_submit_syn_reply (session=0x0, flags=0 '\000', stream_id=33,
> nv=0x2ba4dc1d9c90) at spdylay_submit.c:137
> #1 0x005ef804 in spdy_process_fetch_header (this=0x2ba62cbdc880,
> event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:366
> #2 spdy_process_fetch (this=0x2ba62cbdc880, event=-2, edata=0x2ba68aa47a60)
> at SpdyClientSession.cc:321
> #3 SpdyClientSession::state_session_readwrite (this=0x2ba62cbdc880,
> event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:251
> #4 0x004a46da in handleEvent (this=0x2ba68aa47a60, error_event=0) at
> ../iocore/eventsystem/I_Continuation.h:146
> #5 FetchSM::InvokePluginExt (this=0x2ba68aa47a60, error_event=0) at
> FetchSM.cc:233
> #6 0x004a4bb7 in FetchSM::process_fetch_read (this=0x2ba68aa47a60,
> event=) at FetchSM.cc:400
> #7 0x004a4d6b in FetchSM::fetch_handler (this=0x2ba68aa47a60,
> event=104, edata=0x2ba670cf8a18) at FetchSM.cc:449
> #8 0x004dd82a in PluginVC::process_read_side (this=0x2ba670cf8920,
> other_side_call=false) at PluginVC.cc:637
> #9 0x004df81a in PluginVC::main_handler (this=0x2ba670cf8920,
> event=, data=0x2ba539202740) at PluginVC.cc:208
> #10 0x0073409f in handleEvent (this=0x2ba3b2323010, e=0x2ba539202740,
> calling_code=1) at I_Continuation.h:146
> #11 EThread::process_event (this=0x2ba3b2323010, e=0x2ba539202740,
> calling_code=1) at UnixEThread.cc:145
> #12 0x00734c73 in EThread::execute (this=0x2ba3b2323010) at
> UnixEThread.cc:239
> #13 0x0073344a in spawn_thread_internal (a=0x2645060) at Thread.cc:88
> #14 0x2ba3aaf15851 in start_thread () from /lib64/libpthread.so.0
> #15 0x0038818e894d in clone () from /lib64/libc.so.6
> (gdb) print session
> $36 = (spdylay_session *) 0x0
> (gdb) up
> #1 0x005ef804 in spdy_process_fetch_header (this=0x2ba62cbdc880,
> event=-2, edata=0x2ba68aa47a60) at SpdyClientSession.cc:366
> 366 SpdyClientSession.cc: No such file or directory.
> in SpdyClientSession.cc
> (gdb) print sm->session
> $37 = (spdylay_session *) 0x2ba56ad12130
> (gdb) print *sm->session
> $38 = {streams = {table = 0x2ba5689b86d0, tablelen = 16, size = 0}, ob_pq =
> {q = 0x2ba56989df50, length = 0, capacity = 4096, compar = 0x736a50
> }, ob_ss_pq = {
> q = 0x2ba5681edfd0, length = 0, capacity = 4096, compar = 0x736a50
> }, aob = {item = 0x0, framebuf = 0x2ba64d7e4be0
> "\200\003", framebufmax = 4104,
> framebuflen = 0, framebufoff = 0}, iframe = {inflatebuf = {capacity =
> 4096, root = {data = 0x0, next = 0x0}, current = 0x2ba56ad121b8, len = 0,
> last_offset = 4096},
> buf = 0x2ba56913a3c0 "\300\235'k\245+", headbufoff = 0, bufmax = 4104,
> buflen = 0, payloadlen = 0, off = 0, state = SPDYLAY_RECV_HEAD, error_code =
> 0,
> headbuf = "\000\000\000\000\000\000\000"}, hd_deflater = {zst = {next_in
> = 0x0, avail_in = 0, total_in = 0, next_out = 0x0, avail_out = 0, total_out =
> 0, msg = 0x0,
> state = 0x2ba64f2b6900, zalloc = 0x3882408da0 , zfree =
> 0x3882408d90 , opaque = 0x0, data_type = 2, adler = 3821447106,
> reserved = 0}, version = 3}, hd_inflater = {
> zst = {next_in = 0x0, avail_in = 0, total_in = 0, next_out = 0x0,
> avail_out = 0, total_out = 0, msg = 0x0, state = 0x2ba64cb426e0, zalloc =
> 0x3882408da0 ,
> zfree = 0x3882408d90 , opaque = 0x0, data_type = 0, adler = 1,
> reserved = 0}, version = 3}, cli_certvec = {vector = 0x0, size = 0, capacity
> = 0, last_slot = 0}, callbacks = {
> send_callback = 0x5f15b0 const*, size_t, int, void*)>,
> recv_callback = 0x5f14f0 size_t, int, void*)>,
> on_ctrl_recv_callback = 0x5f1fc0
> spdylay_frame*, void*)>,
> on_invalid_ctrl_recv_callback = 0x5f1000
> spdylay_frame*, uint32_t, void*)>,
> on_data_chunk_recv_callback = 0x5f1ce0
> const*, size_t, void*)>,
> on_data_recv_callback = 0x5f1ad0
> void*)>,
> before_ctrl_send_callback = 0x5f1010
> spdylay_frame*, void*)>,
> on_ctrl_send_callback = 0x5f14d0
> spdylay_frame*, void*)>,
> on_ctrl_not_send_callback = 0x5f1020
> spdylay_frame*, int, void*)>,
> on_data_send_callback = 0x5f16a0
> void*)>,
> on_stream_close_callb
[jira] [Commented] (TS-2889) Crash in FetchSM related to spdy FetchSM changes in 5.0.x
[ https://issues.apache.org/jira/browse/TS-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14034118#comment-14034118 ] Brian Geffon commented on TS-2889: -- There are other crashes in FetchSM, give me a day or two to get my head around it all and I'll post back here. > 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 0x00377c632925 in raise () from /lib64/libc.so.6 > #1 0x00377c634105 in abort () from /lib64/libc.so.6 > #2 0x2b09b0693ef0 in ink_die_die_die (retval=1) at ink_error.cc:43 > #3 0x2b09b0693fbd 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 0x2b09b0694086 in ink_fatal (return_code=1, > message_format=0x2b09b06a1358 "%s:%d: failed assert `%s`") > at ink_error.cc:73 > #5 0x2b09b0692d40 in _ink_assert (expression=0x761f2f "header_done", > file=0x761ede "FetchSM.cc", line=160) at ink_assert.cc:37 > #6 0x004fa5c0 in FetchSM::check_chunked (this=0x2b09f8012240) > at FetchSM.cc:160 > #7 0x004fac82 in FetchSM::get_info_from_buffer (this=0x2b09f8012240, > the_reader=0x2b09f4004818) at FetchSM.cc:313 > #8 0x004fb18b in FetchSM::process_fetch_read (this=0x2b09f8012240, > event=104) at FetchSM.cc:402 > #9 0x004fb42d in FetchSM::fetch_handler (this=0x2b09f8012240, > event=104, edata=0x2b09f8002768) at FetchSM.cc:449 > #10 0x004fc43e in Continuation::handleEvent (this=0x2b09f8012240, > event=104, data=0x2b09f8002768) > at ../iocore/eventsystem/I_Continuation.h:146 > ---Type to continue, or q to quit--- > #11 0x00537f2e in PluginVC::process_read_side (this=0x2b09f8002670, > other_side_call=false) at PluginVC.cc:637 > #12 0x00536856 in PluginVC::main_handler (this=0x2b09f8002670, > event=1, data=0x2b0a340293e0) at PluginVC.cc:208 > #13 0x004fc43e in Continuation::handleEvent (this=0x2b09f8002670, > event=1, data=0x2b0a340293e0) at > ../iocore/eventsystem/I_Continuation.h:146 > #14 0x0075d2e6 in EThread::process_event (this=0x2b09b23cc010, > e=0x2b0a340293e0, calling_code=1) at UnixEThread.cc:145 > #15 0x0075d4b4 in EThread::execute (this=0x2b09b23cc010) > at UnixEThread.cc:196 > #16 0x0075c844 in spawn_thread_internal (a=0x1428b10) at Thread.cc:88 > #17 0x00377ce079d1 in start_thread () from /lib64/libpthread.so.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2889) Crash in FetchSM related to spdy FetchSM changes in 5.0.x
[ https://issues.apache.org/jira/browse/TS-2889?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14034120#comment-14034120 ] Brian Geffon commented on TS-2889: -- [~kichan] Thanks for the help so far. > 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 0x00377c632925 in raise () from /lib64/libc.so.6 > #1 0x00377c634105 in abort () from /lib64/libc.so.6 > #2 0x2b09b0693ef0 in ink_die_die_die (retval=1) at ink_error.cc:43 > #3 0x2b09b0693fbd 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 0x2b09b0694086 in ink_fatal (return_code=1, > message_format=0x2b09b06a1358 "%s:%d: failed assert `%s`") > at ink_error.cc:73 > #5 0x2b09b0692d40 in _ink_assert (expression=0x761f2f "header_done", > file=0x761ede "FetchSM.cc", line=160) at ink_assert.cc:37 > #6 0x004fa5c0 in FetchSM::check_chunked (this=0x2b09f8012240) > at FetchSM.cc:160 > #7 0x004fac82 in FetchSM::get_info_from_buffer (this=0x2b09f8012240, > the_reader=0x2b09f4004818) at FetchSM.cc:313 > #8 0x004fb18b in FetchSM::process_fetch_read (this=0x2b09f8012240, > event=104) at FetchSM.cc:402 > #9 0x004fb42d in FetchSM::fetch_handler (this=0x2b09f8012240, > event=104, edata=0x2b09f8002768) at FetchSM.cc:449 > #10 0x004fc43e in Continuation::handleEvent (this=0x2b09f8012240, > event=104, data=0x2b09f8002768) > at ../iocore/eventsystem/I_Continuation.h:146 > ---Type to continue, or q to quit--- > #11 0x00537f2e in PluginVC::process_read_side (this=0x2b09f8002670, > other_side_call=false) at PluginVC.cc:637 > #12 0x00536856 in PluginVC::main_handler (this=0x2b09f8002670, > event=1, data=0x2b0a340293e0) at PluginVC.cc:208 > #13 0x004fc43e in Continuation::handleEvent (this=0x2b09f8002670, > event=1, data=0x2b0a340293e0) at > ../iocore/eventsystem/I_Continuation.h:146 > #14 0x0075d2e6 in EThread::process_event (this=0x2b09b23cc010, > e=0x2b0a340293e0, calling_code=1) at UnixEThread.cc:145 > #15 0x0075d4b4 in EThread::execute (this=0x2b09b23cc010) > at UnixEThread.cc:196 > #16 0x0075c844 in spawn_thread_internal (a=0x1428b10) at Thread.cc:88 > #17 0x00377ce079d1 in start_thread () from /lib64/libpthread.so.0 -- This message was sent by Atlassian JIRA (v6.2#6252)
