[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)