[jira] [Commented] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent

[Yunkai Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983969#comment-13983969
 ] 

Yunkai Zhang commented on TS-2750:
--

Don't care spdylay library, the crashed backtrace show that freelist was messed 
up.

> Crash with SPDY on production environment in HttpAcceptCont::mainEvent
> --
>
> Key: TS-2750
> URL: https://issues.apache.org/jira/browse/TS-2750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Yunkai Zhang
>  Labels: SPDY_ATS
> Fix For: sometime
>
>
> After applying patches to ts-2742 (removing the ipv4 assert) and ts-2743 (w/ 
> a temporary fix still using the TS API, before a permanent fix is available), 
> noticed the below new core. 
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE: 
> /lib64/libpthread.so.0(+0x329720f500)[0x2b64e0a7a500]
> /home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x563337]
> /home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db38b]
> /home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db673]
> /home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4b53]
> /home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c621b]
> /home/y/bin/traffic_server[0x5d263c]
> /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d33de]
> /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718c10]
> /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719917]
> /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719b49]
> /home/y/bin/traffic_server[0x5d0aa8]
> /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed9e7]
> /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddbe7]
> /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e5052]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712fef]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x713993]
> /home/y/bin/traffic_server[0x71239a]
> /lib64/libpthread.so.0(+0x3297207851)[0x2b64e0a72851]
> /lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent

[Sudheer Vinukonda (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983966#comment-13983966
 ] 

Sudheer Vinukonda commented on TS-2750:
---

>From what I can see in the code, spdylay doesn't seem to use the ats based 
>freelist memory pools. It seems to use malloc/free directly from system heap. 
>I can and will try compiling with reclaimable freelist option to see if it 
>helps, but, I suspect, whatever corruption is happening, is likely within the 
>spdylay library (further evidence from the fact that the core  happens only 
>when spdy is enabled). 

> Crash with SPDY on production environment in HttpAcceptCont::mainEvent
> --
>
> Key: TS-2750
> URL: https://issues.apache.org/jira/browse/TS-2750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Yunkai Zhang
>  Labels: SPDY_ATS
> Fix For: sometime
>
>
> After applying patches to ts-2742 (removing the ipv4 assert) and ts-2743 (w/ 
> a temporary fix still using the TS API, before a permanent fix is available), 
> noticed the below new core. 
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE: 
> /lib64/libpthread.so.0(+0x329720f500)[0x2b64e0a7a500]
> /home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x563337]
> /home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db38b]
> /home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db673]
> /home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4b53]
> /home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c621b]
> /home/y/bin/traffic_server[0x5d263c]
> /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d33de]
> /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718c10]
> /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719917]
> /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719b49]
> /home/y/bin/traffic_server[0x5d0aa8]
> /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed9e7]
> /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddbe7]
> /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e5052]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712fef]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x713993]
> /home/y/bin/traffic_server[0x71239a]
> /lib64/libpthread.so.0(+0x3297207851)[0x2b64e0a72851]
> /lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent

[Yunkai Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983945#comment-13983945
 ] 

Yunkai Zhang edited comment on TS-2750 at 4/29/14 3:33 AM:
---

It seems the freelist of memory pool was corrupt.

You can use reclaimable freelist to help you find out potential double-free 
issue or memory overflow.

By default, double-free checking of reclaimable freelist is disable. You can 
enable it in two ways:

1) Compiles ATS with both {{\-\-enable-reclaimable-freelist}} and 
{{\-\-enable-debug}} option, but unfortunately, {{\-\-enable-debug}} will 
enable all debug assert in the whole project, which may introduce some bad 
side-effect. So I would suggest:

2) Define {{#define DEBUG}} macro in {{ink_queue_ext.h}} header, and compiles 
ATS with {{\-\-enable-reclaimable-freelist}}.






was (Author: yunkai):
It seems the freelist of memory pool was corrupt.

You can use reclaimable freelist to help you find out potential double-free 
issue or memory overflow.

By default, double-free checking of reclaimable freelist is disable. You can 
enable it in two ways:

1) Compiles ATS with both {{\-\-enable-reclaimable-freelist}} and 
{{\-\-enable-debug}} option, but unfortunately, {{\-\-enable-debug}} will 
enable all debug assert in the whole project, which may introduce some bad 
side-effect. So I would suggest:

2) Define "DEBUG = 1" in {{ink_queue_ext.h}} header, and compiles ATS with 
{{\-\-enable-reclaimable-freelist}}.





> Crash with SPDY on production environment in HttpAcceptCont::mainEvent
> --
>
> Key: TS-2750
> URL: https://issues.apache.org/jira/browse/TS-2750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Yunkai Zhang
>  Labels: SPDY_ATS
> Fix For: sometime
>
>
> After applying patches to ts-2742 (removing the ipv4 assert) and ts-2743 (w/ 
> a temporary fix still using the TS API, before a permanent fix is available), 
> noticed the below new core. 
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE: 
> /lib64/libpthread.so.0(+0x329720f500)[0x2b64e0a7a500]
> /home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x563337]
> /home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db38b]
> /home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db673]
> /home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4b53]
> /home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c621b]
> /home/y/bin/traffic_server[0x5d263c]
> /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d33de]
> /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718c10]
> /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719917]
> /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719b49]
> /home/y/bin/traffic_server[0x5d0aa8]
> /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed9e7]
> /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddbe7]
> /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e5052]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712fef]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x713993]
> /home/y/bin/traffic_server[0x71239a]
> /lib64/libpthread.so.0(+0x3297207851)[0x2b64e0a72851]
> /lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent

[Yunkai Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983945#comment-13983945
 ] 

Yunkai Zhang commented on TS-2750:
--

It seems the freelist of memory pool was corrupt.

You can use reclaimable freelist to help you find out potential double-free 
issue or memory overflow.

By default, double-free checking of reclaimable freelist is disable. You can 
enable it in two ways:

1) Compiles ATS with both {{\-\-enable-reclaimable-freelist}} and 
{{\-\-enable-debug}} option, but unfortunately, {{\-\-enable-debug}} will 
enable all debug assert in the whole project, which may introduce some bad 
side-effect. So I would suggest:

2) Define "DEBUG = 1" in {{ink_queue_ext.h}} header, and compiles ATS with 
{{\-\-enable-reclaimable-freelist}}.





> Crash with SPDY on production environment in HttpAcceptCont::mainEvent
> --
>
> Key: TS-2750
> URL: https://issues.apache.org/jira/browse/TS-2750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Yunkai Zhang
>  Labels: SPDY_ATS
> Fix For: sometime
>
>
> After applying patches to ts-2742 (removing the ipv4 assert) and ts-2743 (w/ 
> a temporary fix still using the TS API, before a permanent fix is available), 
> noticed the below new core. 
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE: 
> /lib64/libpthread.so.0(+0x329720f500)[0x2b64e0a7a500]
> /home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x563337]
> /home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db38b]
> /home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db673]
> /home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4b53]
> /home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c621b]
> /home/y/bin/traffic_server[0x5d263c]
> /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d33de]
> /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718c10]
> /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719917]
> /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719b49]
> /home/y/bin/traffic_server[0x5d0aa8]
> /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed9e7]
> /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddbe7]
> /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e5052]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712fef]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x713993]
> /home/y/bin/traffic_server[0x71239a]
> /lib64/libpthread.so.0(+0x3297207851)[0x2b64e0a72851]
> /lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2746) undo accept continuation renaming

[Yunkai Zhang (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983925#comment-13983925
 ] 

Yunkai Zhang commented on TS-2746:
--

nice naming.

> undo accept continuation renaming
> -
>
> Key: TS-2746
> URL: https://issues.apache.org/jira/browse/TS-2746
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cleanup, SPDY
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.0.0
>
>
> In TS-2431, all the FooAccept handlers were renamed to FooAcceptCont. If we 
> added the Cont suffix to everything that was a continuation, there would be 
> no other suffixes. We should undo this, or find a new naming convention.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2564) Segmentation fault in 4.2.0-rc0

[Phil Sorber (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983746#comment-13983746
 ] 

Phil Sorber commented on TS-2564:
-

In thinking about this more, maybe we should remove 5.0.0 from fix versions on 
this and open a new bug for 5.0.0 and close this one?

> Segmentation fault in 4.2.0-rc0
> ---
>
> Key: TS-2564
> URL: https://issues.apache.org/jira/browse/TS-2564
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Bryan Call
>Assignee: Phil Sorber
>Priority: Blocker
>  Labels: crash
> Fix For: 4.2.1, 5.0.0
>
> Attachments: ts-2564-B.diff, ts-2564.diff
>
>
> Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in 
> 4.2.0-rc0:
> {code}
> (gdb) bt
> #0  mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8, 
> field=, detach_all_dups=false) at MIME.cc:469
> #1  mime_hdr_field_detach (mh=0x2acd02e108c8, field=, 
> detach_all_dups=false) at MIME.cc:1538
> #2  0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810, 
> mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups= out>) at MIME.cc:1586
> #3  0x0053cb5b in field_delete (cached_header=0x2acde002fa40, 
> response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
> #4  field_delete (cached_header=0x2acde002fa40, 
> response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
> #5  HttpTransact::merge_response_header_with_cached_header 
> (cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at 
> HttpTransact.cc:4914
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2619) TSRecordDump has a bad declaration

[Phil Sorber (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2619?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983745#comment-13983745
 ] 

Phil Sorber commented on TS-2619:
-

We have a patch for this.

> TSRecordDump has a bad declaration
> --
>
> Key: TS-2619
> URL: https://issues.apache.org/jira/browse/TS-2619
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: James Peach
>Assignee: Phil Sorber
>Priority: Blocker
> Fix For: 5.0.0
>
>
> {{TSRecordDump}} is declared as taking a {{TSRecordType}} constant. However, 
> this API also is defined to be able to operate on a {{TSRecordType}} bit 
> mask. When you do this, you get the following compiler error:
> {code}
> /opt/ats/include/ts/ts.h|3083 col 14| note: candidate function not viable: no 
> known conversion from 'int' to 'TSRecordType' for 1st argument
>  
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TS-2757) deleting stale API logs always crashes

[James Peach (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach updated TS-2757:


Description: 
If you use {{TSTextLogObjectCreate}} in a plugin, when those log objects are 
deleted, the object manager crashes. It looks like {{_APIobjects}} has a stale 
pointer.

{code}
(gdb) bt
#0  0x005e8c47 in LogObjectManager::~LogObjectManager (this=0x4bf0028, 
__in_chrg=) at LogObject.cc:903
#1  0x005d33e2 in LogConfig::~LogConfig (this=0x4bf, 
__in_chrg=) at LogConfig.cc:573
#2  0x005d3446 in LogConfig::~LogConfig (this=0x4bf, 
__in_chrg=) at LogConfig.cc:573
#3  0x00617b8a in ConfigProcessor::release (this=0xafa720, id=5, 
info=0x4bf) at ProxyConfig.cc:210
#4  0x00618496 in ConfigInfoReleaser::handle_event (this=0x21c5a00) at 
ProxyConfig.cc:106
#5  0x004e5920 in Continuation::handleEvent (this=0x21c5a00, event=2, 
data=0xe926780) at ../iocore/eventsystem/I_Continuation.h:146
#6  0x006d17b6 in EThread::process_event (this=0x2e08000, e=0xe926780, 
calling_code=2) at UnixEThread.cc:145
#7  0x006d1ad1 in EThread::execute (this=0x2e08000) at 
UnixEThread.cc:224
#8  0x006d0da0 in spawn_thread_internal (a=0x21ddd60) at Thread.cc:88
#9  0x2b507e273851 in start_thread () from /lib64/libpthread.so.0
{code}

  was:
If you use {{TSTextLogObjectCreate}} in a plugin, when those log objects ate 
deleted, the object manager crashes. It looks like {{_APIobjects}} has a stale 
pointer.

{code}
(gdb) bt
#0  0x005e8c47 in LogObjectManager::~LogObjectManager (this=0x4bf0028, 
__in_chrg=) at LogObject.cc:903
#1  0x005d33e2 in LogConfig::~LogConfig (this=0x4bf, 
__in_chrg=) at LogConfig.cc:573
#2  0x005d3446 in LogConfig::~LogConfig (this=0x4bf, 
__in_chrg=) at LogConfig.cc:573
#3  0x00617b8a in ConfigProcessor::release (this=0xafa720, id=5, 
info=0x4bf) at ProxyConfig.cc:210
#4  0x00618496 in ConfigInfoReleaser::handle_event (this=0x21c5a00) at 
ProxyConfig.cc:106
#5  0x004e5920 in Continuation::handleEvent (this=0x21c5a00, event=2, 
data=0xe926780) at ../iocore/eventsystem/I_Continuation.h:146
#6  0x006d17b6 in EThread::process_event (this=0x2e08000, e=0xe926780, 
calling_code=2) at UnixEThread.cc:145
#7  0x006d1ad1 in EThread::execute (this=0x2e08000) at 
UnixEThread.cc:224
#8  0x006d0da0 in spawn_thread_internal (a=0x21ddd60) at Thread.cc:88
#9  0x2b507e273851 in start_thread () from /lib64/libpthread.so.0
{code}


> deleting stale API logs always crashes
> --
>
> Key: TS-2757
> URL: https://issues.apache.org/jira/browse/TS-2757
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 5.0.0
>Reporter: James Peach
>Assignee: James Peach
>  Labels: A
>
> If you use {{TSTextLogObjectCreate}} in a plugin, when those log objects are 
> deleted, the object manager crashes. It looks like {{_APIobjects}} has a 
> stale pointer.
> {code}
> (gdb) bt
> #0  0x005e8c47 in LogObjectManager::~LogObjectManager 
> (this=0x4bf0028, __in_chrg=) at LogObject.cc:903
> #1  0x005d33e2 in LogConfig::~LogConfig (this=0x4bf, 
> __in_chrg=) at LogConfig.cc:573
> #2  0x005d3446 in LogConfig::~LogConfig (this=0x4bf, 
> __in_chrg=) at LogConfig.cc:573
> #3  0x00617b8a in ConfigProcessor::release (this=0xafa720, id=5, 
> info=0x4bf) at ProxyConfig.cc:210
> #4  0x00618496 in ConfigInfoReleaser::handle_event (this=0x21c5a00) 
> at ProxyConfig.cc:106
> #5  0x004e5920 in Continuation::handleEvent (this=0x21c5a00, event=2, 
> data=0xe926780) at ../iocore/eventsystem/I_Continuation.h:146
> #6  0x006d17b6 in EThread::process_event (this=0x2e08000, 
> e=0xe926780, calling_code=2) at UnixEThread.cc:145
> #7  0x006d1ad1 in EThread::execute (this=0x2e08000) at 
> UnixEThread.cc:224
> #8  0x006d0da0 in spawn_thread_internal (a=0x21ddd60) at Thread.cc:88
> #9  0x2b507e273851 in start_thread () from /lib64/libpthread.so.0
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2564) Segmentation fault in 4.2.0-rc0

[Phil Sorber (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983718#comment-13983718
 ] 

Phil Sorber commented on TS-2564:
-

It's in 4.2.1 and seems to be working. These new reports regard master and I am 
not sure [~amc] has had a chance to look at any of this. We might need to do 
something different there.

> Segmentation fault in 4.2.0-rc0
> ---
>
> Key: TS-2564
> URL: https://issues.apache.org/jira/browse/TS-2564
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Reporter: Bryan Call
>Assignee: Phil Sorber
>Priority: Blocker
>  Labels: crash
> Fix For: 4.2.1, 5.0.0
>
> Attachments: ts-2564-B.diff, ts-2564.diff
>
>
> Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in 
> 4.2.0-rc0:
> {code}
> (gdb) bt
> #0  mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8, 
> field=, detach_all_dups=false) at MIME.cc:469
> #1  mime_hdr_field_detach (mh=0x2acd02e108c8, field=, 
> detach_all_dups=false) at MIME.cc:1538
> #2  0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810, 
> mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups= out>) at MIME.cc:1586
> #3  0x0053cb5b in field_delete (cached_header=0x2acde002fa40, 
> response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
> #4  field_delete (cached_header=0x2acde002fa40, 
> response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
> #5  HttpTransact::merge_response_header_with_cached_header 
> (cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at 
> HttpTransact.cc:4914
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-1983) ACL rules in remap.config does not take precedence over rules in ip_allow.config

[Leif Hedstrom (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-1983?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983629#comment-13983629
 ] 

Leif Hedstrom commented on TS-1983:
---

[~amc] I ran into this again, and it's a PITA...

> ACL rules in remap.config does not take precedence over rules in 
> ip_allow.config
> 
>
> Key: TS-1983
> URL: https://issues.apache.org/jira/browse/TS-1983
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Configuration
>Reporter: Leif Hedstrom
>Assignee: Alan M. Carroll
> Fix For: 5.0.0
>
>
> Lets say you want to allow DELETE for a small sub-set of requests, based on 
> remap.config rules. The reasonable configuration is to do e.g.
> {code}
> map http://dav.example.com http://127.0.0.1 @method=DELETE @action=allow
> {code}
> However, this does not work, since the global "DENY" in ip_allow.config takes 
> precedence (it denies all DELETE's). This is actually sort of a regression I 
> think, it did not use to behave like this I'm fairly certain.
> The workaround (which is incredibly cumbersom if you have even a moderately 
> large remap.config, is to inverse the rules. E.g.
> {code}
> src_ip=0.0.0.0-255.255.255.255action=ip_deny  
> method=PUSH|PURGE
> {code}
> and
> {code}
> map http://other.example.com http://123 @method=DELETE @action=deny
> map http://another.example.com http://123 @method=DELETE @action=deny
> map http://more.example.com http://123 @method=DELETE @action=deny
> .
> .
> .
> {code}
> This kinda sucks to maintain, and also opens up a PEBKAC security  problem, 
> when someone adds a new remap.config rule and forgets to deny the DELETEs.
> I really feel that the ACLs from remap.config (if they match, you can specify 
> IP ranges etc. as well), should take precedence over ip_allow.config.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2755) API is missing TSTextLogObjectRollingEnabledSet argument values

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983626#comment-13983626
 ] 

ASF subversion and git services commented on TS-2755:
-

Commit 56e83bda3639292d10cd403fe94254762560dc83 in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=56e83bd ]

TS-2755: CHANGES


> API is missing TSTextLogObjectRollingEnabledSet argument values
> ---
>
> Key: TS-2755
> URL: https://issues.apache.org/jira/browse/TS-2755
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.0.0
>
>
> The argument to {{TSTextLogObjectRollingEnabledSet}} is a value of type 
> {{LogConfig::RollingEnabledValues}}, however these values are not exposed by 
> the API.
> I'm going to fix this by using the {{enabled}} argument to 
> {{TSTextLogObjectRollingEnabledSet}} as a boolean, since that is consistent 
> with similar APIs. If rolling is enabled, then you will always get 
> {{ROLL_ON_TIME_OR_SIZE}}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2755) API is missing TSTextLogObjectRollingEnabledSet argument values

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983625#comment-13983625
 ] 

ASF subversion and git services commented on TS-2755:
-

Commit 6cbdb672bf7ccc0e3852b734dfe1876759756d91 in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6cbdb67 ]

TS-2755: document TSTextLogObjectRollingEnabledSet


> API is missing TSTextLogObjectRollingEnabledSet argument values
> ---
>
> Key: TS-2755
> URL: https://issues.apache.org/jira/browse/TS-2755
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.0.0
>
>
> The argument to {{TSTextLogObjectRollingEnabledSet}} is a value of type 
> {{LogConfig::RollingEnabledValues}}, however these values are not exposed by 
> the API.
> I'm going to fix this by using the {{enabled}} argument to 
> {{TSTextLogObjectRollingEnabledSet}} as a boolean, since that is consistent 
> with similar APIs. If rolling is enabled, then you will always get 
> {{ROLL_ON_TIME_OR_SIZE}}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2755) API is missing TSTextLogObjectRollingEnabledSet argument values

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2755?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983624#comment-13983624
 ] 

ASF subversion and git services commented on TS-2755:
-

Commit edb3e35bc8261e6125e8bba0be97a4a3c141ce0d in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=edb3e35 ]

TS-2755: use the proper log rolling enum where we can


> API is missing TSTextLogObjectRollingEnabledSet argument values
> ---
>
> Key: TS-2755
> URL: https://issues.apache.org/jira/browse/TS-2755
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.0.0
>
>
> The argument to {{TSTextLogObjectRollingEnabledSet}} is a value of type 
> {{LogConfig::RollingEnabledValues}}, however these values are not exposed by 
> the API.
> I'm going to fix this by using the {{enabled}} argument to 
> {{TSTextLogObjectRollingEnabledSet}} as a boolean, since that is consistent 
> with similar APIs. If rolling is enabled, then you will always get 
> {{ROLL_ON_TIME_OR_SIZE}}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2746) undo accept continuation renaming

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983588#comment-13983588
 ] 

ASF subversion and git services commented on TS-2746:
-

Commit 5ec5921b180e31c478892f2879d780f40979ebe8 in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=5ec5921 ]

TS-2746: rename SpdyAcceptCont to SpdySessionAccept


> undo accept continuation renaming
> -
>
> Key: TS-2746
> URL: https://issues.apache.org/jira/browse/TS-2746
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cleanup, SPDY
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.0.0
>
>
> In TS-2431, all the FooAccept handlers were renamed to FooAcceptCont. If we 
> added the Cont suffix to everything that was a continuation, there would be 
> no other suffixes. We should undo this, or find a new naming convention.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2746) undo accept continuation renaming

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983590#comment-13983590
 ] 

ASF subversion and git services commented on TS-2746:
-

Commit 7f036b4a5a07f2c84ecb6644f3ec843f295bb67f in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=7f036b4 ]

TS-2746: remove the P_ prefix from SPDY headers


> undo accept continuation renaming
> -
>
> Key: TS-2746
> URL: https://issues.apache.org/jira/browse/TS-2746
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cleanup, SPDY
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.0.0
>
>
> In TS-2431, all the FooAccept handlers were renamed to FooAcceptCont. If we 
> added the Cont suffix to everything that was a continuation, there would be 
> no other suffixes. We should undo this, or find a new naming convention.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2746) undo accept continuation renaming

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983591#comment-13983591
 ] 

ASF subversion and git services commented on TS-2746:
-

Commit 81390c57b0563b9b603e543e7e2dfdbf37738c75 in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=81390c5 ]

TS-2746: CHANGES


> undo accept continuation renaming
> -
>
> Key: TS-2746
> URL: https://issues.apache.org/jira/browse/TS-2746
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cleanup, SPDY
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.0.0
>
>
> In TS-2431, all the FooAccept handlers were renamed to FooAcceptCont. If we 
> added the Cont suffix to everything that was a continuation, there would be 
> no other suffixes. We should undo this, or find a new naming convention.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2746) undo accept continuation renaming

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983587#comment-13983587
 ] 

ASF subversion and git services commented on TS-2746:
-

Commit 0d988fd9e0f9f381d5543c9a9d990978bed4966e in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0d988fd ]

TS-2746: rename HttpAcceptCont to HttpSessionAccept


> undo accept continuation renaming
> -
>
> Key: TS-2746
> URL: https://issues.apache.org/jira/browse/TS-2746
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cleanup, SPDY
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.0.0
>
>
> In TS-2431, all the FooAccept handlers were renamed to FooAcceptCont. If we 
> added the Cont suffix to everything that was a continuation, there would be 
> no other suffixes. We should undo this, or find a new naming convention.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2746) undo accept continuation renaming

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983589#comment-13983589
 ] 

ASF subversion and git services commented on TS-2746:
-

Commit 20eb9adbb6bfaeaebc26d552afd3ee816e778dc6 in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=20eb9ad ]

TS-2746: rename ProtocolAcceptCont to ProtocolProbeSessionAccept


> undo accept continuation renaming
> -
>
> Key: TS-2746
> URL: https://issues.apache.org/jira/browse/TS-2746
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cleanup, SPDY
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 5.0.0
>
>
> In TS-2431, all the FooAccept handlers were renamed to FooAcceptCont. If we 
> added the Cont suffix to everything that was a continuation, there would be 
> no other suffixes. We should undo this, or find a new naming convention.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2740) Configuration settings to SPDY support in ATS

[Sudheer Vinukonda (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983556#comment-13983556
 ] 

Sudheer Vinukonda commented on TS-2740:
---

Was wondering about how allowing to configure spdy per ssl cert would impact 
SPDY support for http - or do we simply not support spdy support for http or 
only support it globally for all http ports? 

On the other hand, supporting spdy per port (for either http or https) seems 
possible, although, would like to hear suggestions on the possible 
configuration. Should we support something like spdy:443 (similar to ssl:443) 
for proxy.config.http.server_ports?

> Configuration settings to SPDY support in ATS
> -
>
> Key: TS-2740
> URL: https://issues.apache.org/jira/browse/TS-2740
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, SPDY
>Reporter: Sudheer Vinukonda
>  Labels: SPDY_ATS, yahoo
> Fix For: 5.0.0
>
>
> Would like to use this Jira to add the configuration settings that might be 
> useful to adapt SPDY on ATS
> 1. Currently, SPDY can only be turned on/off via the build with --enable-spdy 
> option. Would like to add a configuration control to turn on/off SPDY 
> capability (useful to troubleshoot production issues) when built with 
> --enable-spdy option.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (TS-2740) Configuration settings to SPDY support in ATS

[Sudheer Vinukonda (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983556#comment-13983556
 ] 

Sudheer Vinukonda edited comment on TS-2740 at 4/28/14 9:17 PM:


Was wondering about how allowing to configure SPDY per ssl cert would impact 
SPDY support for http - or do we simply not support spdy support for http or 
only support it globally for all http ports? 

On the other hand, supporting SPDY per port (for either http or https) seems 
possible, although, would like to hear suggestions on the possible 
configuration. Should we support something like spdy:443 (similar to ssl:443) 
for proxy.config.http.server_ports?


was (Author: sudheerv):
Was wondering about how allowing to configure spdy per ssl cert would impact 
SPDY support for http - or do we simply not support spdy support for http or 
only support it globally for all http ports? 

On the other hand, supporting spdy per port (for either http or https) seems 
possible, although, would like to hear suggestions on the possible 
configuration. Should we support something like spdy:443 (similar to ssl:443) 
for proxy.config.http.server_ports?

> Configuration settings to SPDY support in ATS
> -
>
> Key: TS-2740
> URL: https://issues.apache.org/jira/browse/TS-2740
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, SPDY
>Reporter: Sudheer Vinukonda
>  Labels: SPDY_ATS, yahoo
> Fix For: 5.0.0
>
>
> Would like to use this Jira to add the configuration settings that might be 
> useful to adapt SPDY on ATS
> 1. Currently, SPDY can only be turned on/off via the build with --enable-spdy 
> option. Would like to add a configuration control to turn on/off SPDY 
> capability (useful to troubleshoot production issues) when built with 
> --enable-spdy option.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent

[James Peach (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983374#comment-13983374
 ] 

James Peach edited comment on TS-2750 at 4/28/14 9:07 PM:
--

Looks like there might be some sort of memory corruption - 

{code}
0x2b964c5d5914: Cannot access memory at address 0x2b964c5d5914
(gdb) down
#1  HttpAcceptCont::mainEvent (this=0x28b4b60, event=, 
data=0x2b964c5d5908) at HttpAcceptCont.cc:62
62  HttpAcceptCont.cc: No such file or directory.
in HttpAcceptCont.cc
(gdb) up
#2  0x004db60b in handleEvent (this=0x2b964c5d5710) at 
../iocore/eventsystem/I_Continuation.h:146
146 ../iocore/eventsystem/I_Continuation.h: No such file or directory.
in ../iocore/eventsystem/I_Continuation.h
(gdb) x/x 0x2b964c5d5908
0x2b964c5d5908: Cannot access memory at address 0x2b964c5d5908
{code}

I have a feeling that this may be somehow related (or even contributing to) 
TS-2743


was (Author: sudheerv):
Looks like there might be some sort of memory corruption - 

0x2b964c5d5914: Cannot access memory at address 0x2b964c5d5914
(gdb) down
#1  HttpAcceptCont::mainEvent (this=0x28b4b60, event=, 
data=0x2b964c5d5908) at HttpAcceptCont.cc:62
62  HttpAcceptCont.cc: No such file or directory.
in HttpAcceptCont.cc
(gdb) up
#2  0x004db60b in handleEvent (this=0x2b964c5d5710) at 
../iocore/eventsystem/I_Continuation.h:146
146 ../iocore/eventsystem/I_Continuation.h: No such file or directory.
in ../iocore/eventsystem/I_Continuation.h
(gdb) x/x 0x2b964c5d5908
0x2b964c5d5908: Cannot access memory at address 0x2b964c5d5908

I have a feeling that this may be somehow related (or even contributing to) 
TS-2743

> Crash with SPDY on production environment in HttpAcceptCont::mainEvent
> --
>
> Key: TS-2750
> URL: https://issues.apache.org/jira/browse/TS-2750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Yunkai Zhang
>  Labels: SPDY_ATS
> Fix For: sometime
>
>
> After applying patches to ts-2742 (removing the ipv4 assert) and ts-2743 (w/ 
> a temporary fix still using the TS API, before a permanent fix is available), 
> noticed the below new core. 
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE: 
> /lib64/libpthread.so.0(+0x329720f500)[0x2b64e0a7a500]
> /home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x563337]
> /home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db38b]
> /home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db673]
> /home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4b53]
> /home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c621b]
> /home/y/bin/traffic_server[0x5d263c]
> /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d33de]
> /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718c10]
> /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719917]
> /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719b49]
> /home/y/bin/traffic_server[0x5d0aa8]
> /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed9e7]
> /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddbe7]
> /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e5052]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712fef]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x713993]
> /home/y/bin/traffic_server[0x71239a]
> /lib64/libpthread.so.0(+0x3297207851)[0x2b64e0a72851]
> /lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
> {code}



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent

[James Peach (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983363#comment-13983363
 ] 

James Peach edited comment on TS-2750 at 4/28/14 9:06 PM:
--

OK, the core dump happened again today with the same stack trace. Not sure, why 
it didnt happen over the weekend (perhaps, the weekend traffic mix might have 
been different to that of a weekday).

{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE: 
/lib64/libpthread.so.0(+0x329720f500)[0x2b900b3c8500]
/home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x5635b7]
/home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db60b]
/home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db8f3]
/home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4c73]
/home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c633b]
/home/y/bin/traffic_server[0x5d285c]
/home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d35fe]
/home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718e30]
/home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719b37]
/home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719d69]
/home/y/bin/traffic_server[0x5d0cb8]
/home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6edc07]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6dde07]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e5272]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x71320f]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x713bb3]
/home/y/bin/traffic_server[0x7125ba]
/lib64/libpthread.so.0(+0x3297207851)[0x2b900b3c0851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
{code}


was (Author: sudheerv):
OK, the core dump happened again today with the same stack trace. Not sure, why 
it didnt happen over the weekend (perhaps, the weekend traffic mix might have 
been different to that of a weekday).

NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE: 
/lib64/libpthread.so.0(+0x329720f500)[0x2b900b3c8500]
/home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x5635b7]
/home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db60b]
/home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db8f3]
/home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4c73]
/home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c633b]
/home/y/bin/traffic_server[0x5d285c]
/home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d35fe]
/home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718e30]
/home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719b37]
/home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719d69]
/home/y/bin/traffic_server[0x5d0cb8]
/home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6edc07]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6dde07]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e5272]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x71320f]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x713bb3]
/home/y/bin/traffic_server[0x7125ba]
/lib64/libpthread.so.0(+0x3297207851)[0x2b900b3c0851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]


> Crash with SPDY on production environment in HttpAcceptCont::mainEvent
> --
>
> Key: TS-2750
> URL: https://issues.apache.org/jira/browse/TS-2750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Yunkai Zhang
>  Labels: SPDY_ATS
> Fix For: sometime
>
>
> After applying patches to ts-2742 (removing the ipv4 assert) and ts-2743 (w/ 
> a temporary fix still using the TS API, before a permanent fix is available), 
> noticed the below new core. 
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE: 
> /lib64/libpthread.so.0(+0x329720f500)[0x2b64e0a7a500]
> /home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x563337]
> /home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db38b]
> /home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db673]
> /home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4b53]
> /home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c621b]
> /home/y/bin/traffic_server[0x5d26

[jira] [Comment Edited] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent

[James Peach (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983248#comment-13983248
 ] 

James Peach edited comment on TS-2750 at 4/28/14 9:06 PM:
--

{code}
(gdb) up
#1  HttpAcceptCont::mainEvent (this=0x40dead0, event=, 
data=0x2ab87e071948) at HttpAcceptCont.cc:62
62  HttpClientSession *new_session = 
THREAD_ALLOC_INIT(httpClientSessionAllocator, netvc->thread);
(gdb) up
#2  0x004db5cb in handleEvent (this=0x2ab87e071750) at 
../iocore/eventsystem/I_Continuation.h:146
146 return (this->*handler) (event, data);
(gdb) up
#3  PluginVCCore::state_send_accept (this=0x2ab87e071750) at PluginVC.cc:1118
1118connect_to->handleEvent(NET_EVENT_ACCEPT, &passive_vc);
(gdb) up
#4  0x004db8b3 in PluginVCCore::connect (this=0x2ab87e071750) at 
PluginVC.cc:1064
1064  state_send_accept(EVENT_IMMEDIATE, NULL);
(gdb) up
#5  0x004b4b93 in TSHttpConnectWithProtoStack (addr=0x2ab870a46134, 
proto_stack=4096) at InkAPI.cc:6114
6114PluginVC *return_vc = new_pvc->connect();
(gdb) up
#6  0x004c626a in httpConnect (this=0x2ab870a45f90) at FetchSM.cc:73
73http_vc = TSHttpConnectWithProtoStack(&_addr.sa, proto_stack);
(gdb) up
#7  FetchSM::ext_lanuch (this=0x2ab870a45f90) at FetchSM.cc:523
523 FetchSM::ext_write_data(const void *data, size_t len)
(gdb) up
#8  0x005d287c in spdy_fetcher_launch (req=0x2ab85877bc50, 
method=TS_FETCH_METHOD_GET) at SpdyCallbacks.cc:203
203 
(gdb) up
#9  0x005d361e in spdy_process_syn_stream_frame (session=, type=, frame=, 
user_data=0x2ab85559bfe0) at SpdyCallbacks.cc:288
288  || !req->version.size() || !req->host.size()) {
(gdb) print req
$2 = (SpdyRequest *) 0x2ab85877bc50
(gdb) print *req
$3 = {event = 0, spdy_sm = 0x2ab85559bfe0, stream_id = 129, start_time = 
1398703653423499321, fetch_sm = 0x2ab870a45f90, has_submitted_data = false, 
need_resume_data = false, fetch_data_len = 0, 
  delta_window_size = 0, fetch_body_completed = false, headers = std::vector of 
length 9, capacity 16 = {{first = ":host", second = "sp1.yimg.com"}, {first = 
":method", second = "GET"}, {first = 
":path", second = "/ib/th?id=HN.608041114380075749&pid=15.1"}, {first = 
":scheme", second = "https"}, {first = ":version", second = "HTTP/1.1"}, {first 
= "accept", second = 
"image/png,image/*;q=0.8,*/*;q=0.5"}, {first = "accept-language", second = 
"en-US,en;q=0.5"}, {first = "referer", second = 

"https://images.search.yahoo.com/search/images;_ylt=A0SO8ocUhl5TwAsAHIFXNyoA;_ylu=X3oDMTB0NTF2ZWo3BHNlYwNzYwRjb2xvA2dxMQR2dGlkA1ZJUDA0OV8x?_adv_prop=image&fr=yfp-t-901-s&va=stellar+jay"},
 {
  first = "user-agent", second = "Mozilla/5.0 (Windows NT 6.1; WOW64; 
rv:28.0) Gecko/20100101 Firefox/28.0"}}, url = 
"https://sp1.yimg.com/ib/th?id=HN.608041114380075749&pid=15.1";, host = 
"sp1.yimg.com", path = "/ib/th?id=HN.608041114380075749&pid=15.1", scheme = 
"https", method = "GET", version = "HTTP/1.1", recv_md5 = {A = 1732584193, B = 
4023233417, C = 2562383102, 
D = 271733878, Nl = 0, Nh = 0, data = {0 }, num = 0}}
{code}



was (Author: sudheerv):
(gdb) up
#1  HttpAcceptCont::mainEvent (this=0x40dead0, event=, 
data=0x2ab87e071948) at HttpAcceptCont.cc:62
62  HttpClientSession *new_session = 
THREAD_ALLOC_INIT(httpClientSessionAllocator, netvc->thread);
(gdb) up
#2  0x004db5cb in handleEvent (this=0x2ab87e071750) at 
../iocore/eventsystem/I_Continuation.h:146
146 return (this->*handler) (event, data);
(gdb) up
#3  PluginVCCore::state_send_accept (this=0x2ab87e071750) at PluginVC.cc:1118
1118connect_to->handleEvent(NET_EVENT_ACCEPT, &passive_vc);
(gdb) up
#4  0x004db8b3 in PluginVCCore::connect (this=0x2ab87e071750) at 
PluginVC.cc:1064
1064  state_send_accept(EVENT_IMMEDIATE, NULL);
(gdb) up
#5  0x004b4b93 in TSHttpConnectWithProtoStack (addr=0x2ab870a46134, 
proto_stack=4096) at InkAPI.cc:6114
6114PluginVC *return_vc = new_pvc->connect();
(gdb) up
#6  0x004c626a in httpConnect (this=0x2ab870a45f90) at FetchSM.cc:73
73http_vc = TSHttpConnectWithProtoStack(&_addr.sa, proto_stack);
(gdb) up
#7  FetchSM::ext_lanuch (this=0x2ab870a45f90) at FetchSM.cc:523
523 FetchSM::ext_write_data(const void *data, size_t len)
(gdb) up
#8  0x005d287c in spdy_fetcher_launch (req=0x2ab85877bc50, 
method=TS_FETCH_METHOD_GET) at SpdyCallbacks.cc:203
203 
(gdb) up
#9  0x005d361e in spdy_process_syn_stream_frame (session=, type=, frame=, 
user_data=0x2ab85559bfe0) at SpdyCallbacks.cc:288
288  || !req->version.size() || !req->host.size()) {
(gdb) print req
$2 = (SpdyRequest *) 0x2ab85877bc50
(gdb) print *req
$3 = {event = 0, spdy_sm = 0x2ab85559bfe0, stream_id = 129, start_time = 
1398703653423499321, fetch_sm = 0x2ab870a45f90, has_submitted_data = false, 
need_resume_data = false, fe

[jira] [Updated] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent

[James Peach (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

James Peach updated TS-2750:


Description: 
After applying patches to ts-2742 (removing the ipv4 assert) and ts-2743 (w/ a 
temporary fix still using the TS API, before a permanent fix is available), 
noticed the below new core. 

{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE: 
/lib64/libpthread.so.0(+0x329720f500)[0x2b64e0a7a500]
/home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x563337]
/home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db38b]
/home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db673]
/home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4b53]
/home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c621b]
/home/y/bin/traffic_server[0x5d263c]
/home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d33de]
/home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718c10]
/home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719917]
/home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719b49]
/home/y/bin/traffic_server[0x5d0aa8]
/home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed9e7]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddbe7]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e5052]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712fef]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x713993]
/home/y/bin/traffic_server[0x71239a]
/lib64/libpthread.so.0(+0x3297207851)[0x2b64e0a72851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]
{code}


  was:
After applying patches to ts-2742 (removing the ipv4 assert) and ts-2743 (w/ a 
temporary fix still using the TS API, before a permanent fix is available), 
noticed the below new core. 

NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE: 
/lib64/libpthread.so.0(+0x329720f500)[0x2b64e0a7a500]
/home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x563337]
/home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db38b]
/home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db673]
/home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4b53]
/home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c621b]
/home/y/bin/traffic_server[0x5d263c]
/home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d33de]
/home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718c10]
/home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719917]
/home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719b49]
/home/y/bin/traffic_server[0x5d0aa8]
/home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed9e7]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddbe7]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e5052]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712fef]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x713993]
/home/y/bin/traffic_server[0x71239a]
/lib64/libpthread.so.0(+0x3297207851)[0x2b64e0a72851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]



> Crash with SPDY on production environment in HttpAcceptCont::mainEvent
> --
>
> Key: TS-2750
> URL: https://issues.apache.org/jira/browse/TS-2750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Yunkai Zhang
>  Labels: SPDY_ATS
> Fix For: sometime
>
>
> After applying patches to ts-2742 (removing the ipv4 assert) and ts-2743 (w/ 
> a temporary fix still using the TS API, before a permanent fix is available), 
> noticed the below new core. 
> {code}
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE: 
> /lib64/libpthread.so.0(+0x329720f500)[0x2b64e0a7a500]
> /home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x563337]
> /home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db38b]
> /home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db673]
> /home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4b53]
> /home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c621b]
> /home/y/bin/traffic_server[0x5d263c]
> /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0

[jira] [Comment Edited] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent

[James Peach (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983369#comment-13983369
 ] 

James Peach edited comment on TS-2750 at 4/28/14 9:07 PM:
--

Here's the gdb output from the latest crash:

{code}
(gdb) bt
#0  thread_alloc_init (this=0x28b4b60, event=, data=0x2b964c5d5908) at 
../../iocore/eventsystem/I_ProxyAllocator.h:71
#1  HttpAcceptCont::mainEvent (this=0x28b4b60, event=, 
data=0x2b964c5d5908) at HttpAcceptCont.cc:62
#2  0x004db60b in handleEvent (this=0x2b964c5d5710) at 
../iocore/eventsystem/I_Continuation.h:146
#3  PluginVCCore::state_send_accept (this=0x2b964c5d5710) at PluginVC.cc:1118
#4  0x004db8f3 in PluginVCCore::connect (this=0x2b964c5d5710) at 
PluginVC.cc:1064
#5  0x004b4c73 in TSHttpConnectWithProtoStack (addr=0x2b950c2f3824, 
proto_stack=8196) at InkAPI.cc:6114
#6  0x004c633b in httpConnect (this=0x2b950c2f3680) at FetchSM.cc:73
#7  FetchSM::ext_lanuch (this=0x2b950c2f3680) at FetchSM.cc:519
#8  0x005d285c in spdy_fetcher_launch (req=0x2b90fe269e20, 
method=TS_FETCH_METHOD_GET) at SpdyCallbacks.cc:209
#9  0x005d35fe in spdy_process_syn_stream_frame (session=, type=, frame=, 
user_data=0x2b9108026910) at SpdyCallbacks.cc:294
#10 spdy_on_ctrl_recv_callback (session=, type=, frame=, user_data=0x2b9108026910) at 
SpdyCallbacks.cc:332
#11 0x00718e30 in spdylay_session_on_syn_stream_received 
(session=0x2b95ee74e490, frame=0x2b902621e9e0) at spdylay_session.c:1782
#12 0x00719b37 in spdylay_session_process_ctrl_frame 
(session=0x2b95ee74e490, in=0x2b902621ea50 "\200\003", inlen=) at spdylay_session.c:2246
#13 spdylay_session_mem_recv (session=0x2b95ee74e490, in=0x2b902621ea50 
"\200\003", inlen=) at spdylay_session.c:2805
#14 0x00719d69 in spdylay_session_recv (session=0x2b95ee74e490) at 
spdylay_session.c:2828
#15 0x005d0cb8 in spdy_process_read (contp=, 
event=TS_EVENT_VCONN_READ_READY, edata=) at SpdySM.cc:263
#16 spdy_default_handler (contp=, 
event=TS_EVENT_VCONN_READ_READY, edata=) at SpdySM.cc:233
#17 0x006edc07 in handleEvent (this=0x2b9138bf2090, event=) at ../../iocore/eventsystem/I_Continuation.h:146
#18 read_signal_and_update (this=0x2b9138bf2090, event=) 
at UnixNetVConnection.cc:216
#19 UnixNetVConnection::readSignalAndUpdate (this=0x2b9138bf2090, event=) at UnixNetVConnection.cc:998
#20 0x006dde07 in SSLNetVConnection::net_read_io (this=0x2b9138bf2090, 
nh=0x2b902490ec10, lthread=0x2b902490b010) at SSLNetVConnection.cc:294
#21 0x006e5272 in NetHandler::mainNetEvent (this=0x2b902490ec10, 
event=, e=) at UnixNet.cc:384
#22 0x0071320f in handleEvent (this=0x2b902490b010, e=0x1829d70, 
calling_code=5) at I_Continuation.h:146
#23 EThread::process_event (this=0x2b902490b010, e=0x1829d70, calling_code=5) 
at UnixEThread.cc:145
#24 0x00713bb3 in EThread::execute (this=0x2b902490b010) at 
UnixEThread.cc:269
#25 0x007125ba in spawn_thread_internal (a=0x1afc750) at Thread.cc:88
#26 0x2b900b3c0851 in start_thread () from /lib64/libpthread.so.0
#27 0x003296ee890d in clone () from /lib64/libc.so.6
(gdb) p v
Cannot access memory at address 0x2b964c5d5998
(gdb) p l
Cannot access memory at address 0x2b964c5d5998
(gdb) p a
$1 = 
{code}


was (Author: sudheerv):
Here's the gdb output from the latest crash:


(gdb) bt
#0  thread_alloc_init (this=0x28b4b60, event=, data=0x2b964c5d5908) at 
../../iocore/eventsystem/I_ProxyAllocator.h:71
#1  HttpAcceptCont::mainEvent (this=0x28b4b60, event=, 
data=0x2b964c5d5908) at HttpAcceptCont.cc:62
#2  0x004db60b in handleEvent (this=0x2b964c5d5710) at 
../iocore/eventsystem/I_Continuation.h:146
#3  PluginVCCore::state_send_accept (this=0x2b964c5d5710) at PluginVC.cc:1118
#4  0x004db8f3 in PluginVCCore::connect (this=0x2b964c5d5710) at 
PluginVC.cc:1064
#5  0x004b4c73 in TSHttpConnectWithProtoStack (addr=0x2b950c2f3824, 
proto_stack=8196) at InkAPI.cc:6114
#6  0x004c633b in httpConnect (this=0x2b950c2f3680) at FetchSM.cc:73
#7  FetchSM::ext_lanuch (this=0x2b950c2f3680) at FetchSM.cc:519
#8  0x005d285c in spdy_fetcher_launch (req=0x2b90fe269e20, 
method=TS_FETCH_METHOD_GET) at SpdyCallbacks.cc:209
#9  0x005d35fe in spdy_process_syn_stream_frame (session=, type=, frame=, 
user_data=0x2b9108026910) at SpdyCallbacks.cc:294
#10 spdy_on_ctrl_recv_callback (session=, type=, frame=, user_data=0x2b9108026910) at 
SpdyCallbacks.cc:332
#11 0x00718e30 in spdylay_session_on_syn_stream_received 
(session=0x2b95ee74e490, frame=0x2b902621e9e0) at spdylay_session.c:1782
#12 0x00719b37 in spdylay_session_process_ctrl_frame 
(session=0x2b95ee74e490, in=0x2b902621ea50 "\200\003", inlen=) at spdylay_session.c:2246
#13 spdylay_session_mem_recv (session=0x2b95ee74e490, in=0x2b902621ea50 
"\200\003", inlen=) at spdylay_session.c:2805
#14 0x

[jira] [Comment Edited] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent

[James Peach (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983245#comment-13983245
 ] 

James Peach edited comment on TS-2750 at 4/28/14 9:06 PM:
--

Strangely, I've not been able to reproduce this core since Friday evening. 
There hasn't been any changes on the ATS version that I have been using, but, 
it looks to be running fine since Friday. Will continue to monitor and report 
back if I see it again.

In the mean time, below's the stack trace from gdb for this core from Friday 
morning.

{code}
#0  thread_alloc_init (this=0x40dead0, event=, data=0x2ab87e071948) at 
../../iocore/eventsystem/I_ProxyAllocator.h:71
71  memcpy((void *) v, (void *) &a.proto.typeObject, sizeof(C));
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.132.el6.x86_64 
gmp-4.3.1-7.el6_2.2.x86_64 hwloc-1.5-1.el6.x86_64 
keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.10.3-10.el6_4.6.x86_64 
libattr-2.4.44-7.el6.x86_64 libcap-2.16-5.5.el6.x86_64 
libcom_err-1.41.12-18.el6.x86_64 libgcc-4.4.7-4.el6.x86_64 
libselinux-2.0.94-5.3.el6_4.1.x86_64 libstdc++-4.4.7-4.el6.x86_64 
libxml2-2.7.6-14.el6.x86_64 nss-softokn-freebl-3.14.3-9.el6.x86_64 
numactl-2.0.7-8.el6.x86_64 openssl-1.0.1e-16.el6_5.4.x86_64 
pciutils-libs-3.1.10-2.el6.x86_64 pcre-7.8-6.el6.x86_64 tcl-8.5.7-6.el6.x86_64 
xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0  thread_alloc_init (this=0x40dead0, event=, data=0x2ab87e071948) at 
../../iocore/eventsystem/I_ProxyAllocator.h:71
#1  HttpAcceptCont::mainEvent (this=0x40dead0, event=, 
data=0x2ab87e071948) at HttpAcceptCont.cc:62
#2  0x004db5cb in handleEvent (this=0x2ab87e071750) at 
../iocore/eventsystem/I_Continuation.h:146
#3  PluginVCCore::state_send_accept (this=0x2ab87e071750) at PluginVC.cc:1118
#4  0x004db8b3 in PluginVCCore::connect (this=0x2ab87e071750) at 
PluginVC.cc:1064
#5  0x004b4b93 in TSHttpConnectWithProtoStack (addr=0x2ab870a46134, 
proto_stack=4096) at InkAPI.cc:6114
#6  0x004c626a in httpConnect (this=0x2ab870a45f90) at FetchSM.cc:73
#7  FetchSM::ext_lanuch (this=0x2ab870a45f90) at FetchSM.cc:523
#8  0x005d287c in spdy_fetcher_launch (req=0x2ab85877bc50, 
method=TS_FETCH_METHOD_GET) at SpdyCallbacks.cc:203
#9  0x005d361e in spdy_process_syn_stream_frame (session=, type=, frame=, 
user_data=0x2ab85559bfe0) at SpdyCallbacks.cc:288
#10 spdy_on_ctrl_recv_callback (session=, type=, frame=, user_data=0x2ab85559bfe0) at 
SpdyCallbacks.cc:326
#11 0x00718e50 in spdylay_session_on_syn_stream_received 
(session=0x2ab87d649060, frame=0x2ab79ce509e0) at spdylay_session.c:1782
#12 0x00719b57 in spdylay_session_process_ctrl_frame 
(session=0x2ab87d649060, in=0x2ab79ce50a50 "\200\003", inlen=) at spdylay_session.c:2246
#13 spdylay_session_mem_recv (session=0x2ab87d649060, in=0x2ab79ce50a50 
"\200\003", inlen=) at spdylay_session.c:2805
#14 0x00719d89 in spdylay_session_recv (session=0x2ab87d649060) at 
spdylay_session.c:2828
#15 0x005d0ce8 in spdy_process_read (contp=, 
event=TS_EVENT_VCONN_READ_READY, edata=) at SpdySM.cc:263
#16 spdy_default_handler (contp=, 
event=TS_EVENT_VCONN_READ_READY, edata=) at SpdySM.cc:233
#17 0x006edc27 in handleEvent (this=0x2ab8c821fe10, event=) at ../../iocore/eventsystem/I_Continuation.h:146
#18 read_signal_and_update (this=0x2ab8c821fe10, event=) 
at UnixNetVConnection.cc:216
#19 UnixNetVConnection::readSignalAndUpdate (this=0x2ab8c821fe10, event=) at UnixNetVConnection.cc:998
#20 0x006dde27 in SSLNetVConnection::net_read_io (this=0x2ab8c821fe10, 
nh=0x2ab79b540c10, lthread=0x2ab79b53d010) at SSLNetVConnection.cc:294
#21 0x006e5292 in NetHandler::mainNetEvent (this=0x2ab79b540c10, 
event=, e=) at UnixNet.cc:384
#22 0x0071322f in handleEvent (this=0x2ab79b53d010, e=0x3053c50, 
calling_code=5) at I_Continuation.h:146
#23 EThread::process_event (this=0x2ab79b53d010, e=0x3053c50, calling_code=5) 
at UnixEThread.cc:145
#24 0x00713bd3 in EThread::execute (this=0x2ab79b53d010) at 
UnixEThread.cc:269
#25 0x007125da in spawn_thread_internal (a=0x3308ef0) at Thread.cc:88
#26 0x2ab786c6f851 in __free_tcb () from /lib64/libpthread.so.0
#27 0x in ?? ()
{code}




was (Author: sudheerv):
Strangely, I've not been able to reproduce this core since Friday evening. 
There hasn't been any changes on the ATS version that I have been using, but, 
it looks to be running fine since Friday. Will continue to monitor and report 
back if I see it again.

In the mean time, below's the stack trace from gdb for this core from Friday 
morning.

#0  thread_alloc_init (this=0x40dead0, event=, data=0x2ab87e071948) at 
../../iocore/eventsystem/I_ProxyAllocator.h:71
71  memcpy((void *) v, (void *) &a.proto.typeObject, sizeof(C));
Missing separate debuginfos, use: debuginfo-insta

[jira] [Commented] (TS-2754) tcpinfo plugin skips transaction close

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983528#comment-13983528
 ] 

ASF subversion and git services commented on TS-2754:
-

Commit 44236aec23565b59c16aaa3987b132c0a261fda7 in trafficserver's branch 
refs/heads/master from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=44236ae ]

TS-2754: emit a tcpinfo log on TS_EVENT_HTTP_TXN_CLOSE

The tcpinfo plugin should emit a log entry when it receives the
TS_EVENT_HTTP_TXN_CLOSE event.


> tcpinfo plugin skips transaction close
> --
>
> Key: TS-2754
> URL: https://issues.apache.org/jira/browse/TS-2754
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Affects Versions: 5.0.0
>Reporter: James Peach
>Assignee: James Peach
>Priority: Minor
> Fix For: 5.0.0
>
>
> The {{tcpinfo}} plugin skips the {{TS_EVENT_HTTP_TXN_CLOSE}} event, so it 
> fails to log at that point.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Created] (TS-2761) Weird behavior of read-while-write

[Faysal Banna (JIRA)]

Faysal Banna created TS-2761:


 Summary: Weird behavior of read-while-write 
 Key: TS-2761
 URL: https://issues.apache.org/jira/browse/TS-2761
 Project: Traffic Server
  Issue Type: Bug
  Components: Cache, Performance, Quality
Reporter: Faysal Banna


Hello.
There is an issue with read-while-write stuff in ATS that is explained as 
follows :
If a client starts a file download lets say 10MB file,  and after couple of 
seconds another client coincidentally requests this same file.

When client1 terminates the file download for any reason,  supposedly client2 
should take over and continue the download till it gets saved, yet
 whats happening here is that client2 gets connection interrupted after 
whatever is configured in proxy.config.http.background_fill_active_timeout.
And then re-initiates another request in a Range header and thus the file is 
never saved.
isn't this unpleasant to deal with read_while_revalidate and cache saving 
process ? 
Imagine  a 200MB windows update file, defenetly we need that saved in the cache.
look at the situation where  You have 10 clients watching a movie that am happy 
that my server is caching it .. suddenly first client who initially requested 
the movie aborts all the remaining 9 clients would get interrupted and each one 
requests a new file with range header
and thus now i shall be getting 9 different requests for the same movie with 
range header which is never cached and thus instead of saving bandwidth you 
shall be consuming bandwidth for the same file(object) 9 times.

In my opinion background fill should take over only if no one is consuming the 
connection(request) anymore, and thus it may timeout with whatever timeout it 
holds in config.

Much Regards 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-645) Hard restart in the mgmt APIs is totally busted

[JIRA]

[ 
https://issues.apache.org/jira/browse/TS-645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983486#comment-13983486
 ] 

Igor Galić commented on TS-645:
---

thanks a lot

> Hard restart in the mgmt APIs is totally busted
> ---
>
> Key: TS-645
> URL: https://issues.apache.org/jira/browse/TS-645
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Management API
>Reporter: Leif Hedstrom
>Assignee: Igor Galić
>  Labels: A, review
> Fix For: 5.0.0
>
>
> In CoreAPIRemote.cc, in HardRestart(), we assume to find some start / stop 
> scripts that no longer exists:
>   Layout::relative_to(start_path, sizeof(start_path), Layout::get()->bindir, 
> "start_traffic_server");
>   Layout::relative_to(stop_path, sizeof(stop_path), Layout::get()->bindir, 
> "stop_traffic_server");
> I don't know if / when this would be used (probably only in the deprecated 
> Web GUI at this point), but we should fix this.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent

[Sudheer Vinukonda (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983374#comment-13983374
 ] 

Sudheer Vinukonda edited comment on TS-2750 at 4/28/14 6:37 PM:


Looks like there might be some sort of memory corruption - 

0x2b964c5d5914: Cannot access memory at address 0x2b964c5d5914
(gdb) down
#1  HttpAcceptCont::mainEvent (this=0x28b4b60, event=, 
data=0x2b964c5d5908) at HttpAcceptCont.cc:62
62  HttpAcceptCont.cc: No such file or directory.
in HttpAcceptCont.cc
(gdb) up
#2  0x004db60b in handleEvent (this=0x2b964c5d5710) at 
../iocore/eventsystem/I_Continuation.h:146
146 ../iocore/eventsystem/I_Continuation.h: No such file or directory.
in ../iocore/eventsystem/I_Continuation.h
(gdb) x/x 0x2b964c5d5908
0x2b964c5d5908: Cannot access memory at address 0x2b964c5d5908

I have a feeling that this is also the root cause behind ts-2743



was (Author: sudheerv):
Looks like there might be some sort of memory corruption - 

0x2b964c5d5914: Cannot access memory at address 0x2b964c5d5914
(gdb) down
#1  HttpAcceptCont::mainEvent (this=0x28b4b60, event=, 
data=0x2b964c5d5908) at HttpAcceptCont.cc:62
62  HttpAcceptCont.cc: No such file or directory.
in HttpAcceptCont.cc
(gdb) up
#2  0x004db60b in handleEvent (this=0x2b964c5d5710) at 
../iocore/eventsystem/I_Continuation.h:146
146 ../iocore/eventsystem/I_Continuation.h: No such file or directory.
in ../iocore/eventsystem/I_Continuation.h
(gdb) x/x 0x2b964c5d5908
0x2b964c5d5908: Cannot access memory at address 0x2b964c5d5908


> Crash with SPDY on production environment in HttpAcceptCont::mainEvent
> --
>
> Key: TS-2750
> URL: https://issues.apache.org/jira/browse/TS-2750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Yunkai Zhang
>  Labels: SPDY_ATS
> Fix For: sometime
>
>
> After applying patches to ts-2742 (removing the ipv4 assert) and ts-2743 (w/ 
> a temporary fix still using the TS API, before a permanent fix is available), 
> noticed the below new core. 
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE: 
> /lib64/libpthread.so.0(+0x329720f500)[0x2b64e0a7a500]
> /home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x563337]
> /home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db38b]
> /home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db673]
> /home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4b53]
> /home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c621b]
> /home/y/bin/traffic_server[0x5d263c]
> /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d33de]
> /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718c10]
> /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719917]
> /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719b49]
> /home/y/bin/traffic_server[0x5d0aa8]
> /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed9e7]
> /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddbe7]
> /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e5052]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712fef]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x713993]
> /home/y/bin/traffic_server[0x71239a]
> /lib64/libpthread.so.0(+0x3297207851)[0x2b64e0a72851]
> /lib64/libc.so.6(clone+0x6d)[0x3296ee890d]



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent

[Sudheer Vinukonda (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983374#comment-13983374
 ] 

Sudheer Vinukonda commented on TS-2750:
---

Looks like there might be some sort of memory corruption - 

0x2b964c5d5914: Cannot access memory at address 0x2b964c5d5914
(gdb) down
#1  HttpAcceptCont::mainEvent (this=0x28b4b60, event=, 
data=0x2b964c5d5908) at HttpAcceptCont.cc:62
62  HttpAcceptCont.cc: No such file or directory.
in HttpAcceptCont.cc
(gdb) up
#2  0x004db60b in handleEvent (this=0x2b964c5d5710) at 
../iocore/eventsystem/I_Continuation.h:146
146 ../iocore/eventsystem/I_Continuation.h: No such file or directory.
in ../iocore/eventsystem/I_Continuation.h
(gdb) x/x 0x2b964c5d5908
0x2b964c5d5908: Cannot access memory at address 0x2b964c5d5908


> Crash with SPDY on production environment in HttpAcceptCont::mainEvent
> --
>
> Key: TS-2750
> URL: https://issues.apache.org/jira/browse/TS-2750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Yunkai Zhang
>  Labels: SPDY_ATS
> Fix For: sometime
>
>
> After applying patches to ts-2742 (removing the ipv4 assert) and ts-2743 (w/ 
> a temporary fix still using the TS API, before a permanent fix is available), 
> noticed the below new core. 
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE: 
> /lib64/libpthread.so.0(+0x329720f500)[0x2b64e0a7a500]
> /home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x563337]
> /home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db38b]
> /home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db673]
> /home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4b53]
> /home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c621b]
> /home/y/bin/traffic_server[0x5d263c]
> /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d33de]
> /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718c10]
> /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719917]
> /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719b49]
> /home/y/bin/traffic_server[0x5d0aa8]
> /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed9e7]
> /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddbe7]
> /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e5052]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712fef]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x713993]
> /home/y/bin/traffic_server[0x71239a]
> /lib64/libpthread.so.0(+0x3297207851)[0x2b64e0a72851]
> /lib64/libc.so.6(clone+0x6d)[0x3296ee890d]



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent

[Sudheer Vinukonda (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983374#comment-13983374
 ] 

Sudheer Vinukonda edited comment on TS-2750 at 4/28/14 6:38 PM:


Looks like there might be some sort of memory corruption - 

0x2b964c5d5914: Cannot access memory at address 0x2b964c5d5914
(gdb) down
#1  HttpAcceptCont::mainEvent (this=0x28b4b60, event=, 
data=0x2b964c5d5908) at HttpAcceptCont.cc:62
62  HttpAcceptCont.cc: No such file or directory.
in HttpAcceptCont.cc
(gdb) up
#2  0x004db60b in handleEvent (this=0x2b964c5d5710) at 
../iocore/eventsystem/I_Continuation.h:146
146 ../iocore/eventsystem/I_Continuation.h: No such file or directory.
in ../iocore/eventsystem/I_Continuation.h
(gdb) x/x 0x2b964c5d5908
0x2b964c5d5908: Cannot access memory at address 0x2b964c5d5908

I have a feeling that this may be somehow related (or even contributing to) 
TS-2743


was (Author: sudheerv):
Looks like there might be some sort of memory corruption - 

0x2b964c5d5914: Cannot access memory at address 0x2b964c5d5914
(gdb) down
#1  HttpAcceptCont::mainEvent (this=0x28b4b60, event=, 
data=0x2b964c5d5908) at HttpAcceptCont.cc:62
62  HttpAcceptCont.cc: No such file or directory.
in HttpAcceptCont.cc
(gdb) up
#2  0x004db60b in handleEvent (this=0x2b964c5d5710) at 
../iocore/eventsystem/I_Continuation.h:146
146 ../iocore/eventsystem/I_Continuation.h: No such file or directory.
in ../iocore/eventsystem/I_Continuation.h
(gdb) x/x 0x2b964c5d5908
0x2b964c5d5908: Cannot access memory at address 0x2b964c5d5908

I have a feeling that this is also the root cause behind ts-2743


> Crash with SPDY on production environment in HttpAcceptCont::mainEvent
> --
>
> Key: TS-2750
> URL: https://issues.apache.org/jira/browse/TS-2750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Yunkai Zhang
>  Labels: SPDY_ATS
> Fix For: sometime
>
>
> After applying patches to ts-2742 (removing the ipv4 assert) and ts-2743 (w/ 
> a temporary fix still using the TS API, before a permanent fix is available), 
> noticed the below new core. 
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE: 
> /lib64/libpthread.so.0(+0x329720f500)[0x2b64e0a7a500]
> /home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x563337]
> /home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db38b]
> /home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db673]
> /home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4b53]
> /home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c621b]
> /home/y/bin/traffic_server[0x5d263c]
> /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d33de]
> /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718c10]
> /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719917]
> /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719b49]
> /home/y/bin/traffic_server[0x5d0aa8]
> /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed9e7]
> /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddbe7]
> /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e5052]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712fef]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x713993]
> /home/y/bin/traffic_server[0x71239a]
> /lib64/libpthread.so.0(+0x3297207851)[0x2b64e0a72851]
> /lib64/libc.so.6(clone+0x6d)[0x3296ee890d]



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent

[Sudheer Vinukonda (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983369#comment-13983369
 ] 

Sudheer Vinukonda commented on TS-2750:
---

Here's the gdb output from the latest crash:


(gdb) bt
#0  thread_alloc_init (this=0x28b4b60, event=, data=0x2b964c5d5908) at 
../../iocore/eventsystem/I_ProxyAllocator.h:71
#1  HttpAcceptCont::mainEvent (this=0x28b4b60, event=, 
data=0x2b964c5d5908) at HttpAcceptCont.cc:62
#2  0x004db60b in handleEvent (this=0x2b964c5d5710) at 
../iocore/eventsystem/I_Continuation.h:146
#3  PluginVCCore::state_send_accept (this=0x2b964c5d5710) at PluginVC.cc:1118
#4  0x004db8f3 in PluginVCCore::connect (this=0x2b964c5d5710) at 
PluginVC.cc:1064
#5  0x004b4c73 in TSHttpConnectWithProtoStack (addr=0x2b950c2f3824, 
proto_stack=8196) at InkAPI.cc:6114
#6  0x004c633b in httpConnect (this=0x2b950c2f3680) at FetchSM.cc:73
#7  FetchSM::ext_lanuch (this=0x2b950c2f3680) at FetchSM.cc:519
#8  0x005d285c in spdy_fetcher_launch (req=0x2b90fe269e20, 
method=TS_FETCH_METHOD_GET) at SpdyCallbacks.cc:209
#9  0x005d35fe in spdy_process_syn_stream_frame (session=, type=, frame=, 
user_data=0x2b9108026910) at SpdyCallbacks.cc:294
#10 spdy_on_ctrl_recv_callback (session=, type=, frame=, user_data=0x2b9108026910) at 
SpdyCallbacks.cc:332
#11 0x00718e30 in spdylay_session_on_syn_stream_received 
(session=0x2b95ee74e490, frame=0x2b902621e9e0) at spdylay_session.c:1782
#12 0x00719b37 in spdylay_session_process_ctrl_frame 
(session=0x2b95ee74e490, in=0x2b902621ea50 "\200\003", inlen=) at spdylay_session.c:2246
#13 spdylay_session_mem_recv (session=0x2b95ee74e490, in=0x2b902621ea50 
"\200\003", inlen=) at spdylay_session.c:2805
#14 0x00719d69 in spdylay_session_recv (session=0x2b95ee74e490) at 
spdylay_session.c:2828
#15 0x005d0cb8 in spdy_process_read (contp=, 
event=TS_EVENT_VCONN_READ_READY, edata=) at SpdySM.cc:263
#16 spdy_default_handler (contp=, 
event=TS_EVENT_VCONN_READ_READY, edata=) at SpdySM.cc:233
#17 0x006edc07 in handleEvent (this=0x2b9138bf2090, event=) at ../../iocore/eventsystem/I_Continuation.h:146
#18 read_signal_and_update (this=0x2b9138bf2090, event=) 
at UnixNetVConnection.cc:216
#19 UnixNetVConnection::readSignalAndUpdate (this=0x2b9138bf2090, event=) at UnixNetVConnection.cc:998
#20 0x006dde07 in SSLNetVConnection::net_read_io (this=0x2b9138bf2090, 
nh=0x2b902490ec10, lthread=0x2b902490b010) at SSLNetVConnection.cc:294
#21 0x006e5272 in NetHandler::mainNetEvent (this=0x2b902490ec10, 
event=, e=) at UnixNet.cc:384
#22 0x0071320f in handleEvent (this=0x2b902490b010, e=0x1829d70, 
calling_code=5) at I_Continuation.h:146
#23 EThread::process_event (this=0x2b902490b010, e=0x1829d70, calling_code=5) 
at UnixEThread.cc:145
#24 0x00713bb3 in EThread::execute (this=0x2b902490b010) at 
UnixEThread.cc:269
#25 0x007125ba in spawn_thread_internal (a=0x1afc750) at Thread.cc:88
#26 0x2b900b3c0851 in start_thread () from /lib64/libpthread.so.0
#27 0x003296ee890d in clone () from /lib64/libc.so.6
(gdb) p v
Cannot access memory at address 0x2b964c5d5998
(gdb) p l
Cannot access memory at address 0x2b964c5d5998
(gdb) p a
$1 = 


> Crash with SPDY on production environment in HttpAcceptCont::mainEvent
> --
>
> Key: TS-2750
> URL: https://issues.apache.org/jira/browse/TS-2750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Yunkai Zhang
>  Labels: SPDY_ATS
> Fix For: sometime
>
>
> After applying patches to ts-2742 (removing the ipv4 assert) and ts-2743 (w/ 
> a temporary fix still using the TS API, before a permanent fix is available), 
> noticed the below new core. 
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE: 
> /lib64/libpthread.so.0(+0x329720f500)[0x2b64e0a7a500]
> /home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x563337]
> /home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db38b]
> /home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db673]
> /home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4b53]
> /home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c621b]
> /home/y/bin/traffic_server[0x5d263c]
> /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d33de]
> /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718c10]
> /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719917]
> /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719b49]
> /home/y/bin/traffic_server[0x5d0aa8]
> /home/y/b

[jira] [Commented] (TS-2497) Failed post results in tunnel buffers being returned to freelist prematurely

[Brian Geffon (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983370#comment-13983370
 ] 

Brian Geffon commented on TS-2497:
--

Hi Shaun, do you have a test that we can use to try to reproduce this, I have 
verified that the buffers were freed on 3.2.4, but it's possible I missed an 
edge case.

> Failed post results in tunnel buffers being returned to freelist prematurely
> 
>
> Key: TS-2497
> URL: https://issues.apache.org/jira/browse/TS-2497
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 4.2.0
>
>
> When a post fails to an origin server either the server died or the server 
> returned a response without reading all of the post data, in either case, TS 
> will destroy buffers too early. This normally does not result in a crash 
> because the MIOBuffers are returned to the freelist and only with sufficient 
> load will the race happen causing a crash. Additionally, even if a crash 
> doesn't happen you might have data corruption across post requests from the 
> buffers being used after being returned to the freelist.
> Thanks to Thomas Jackson for help reproducing and resolving this bug.
> An example stack trace, while we've seen other crashes in write_avail too.
> #0  0x004eff14 in IOBufferBlock::read_avail (this=0x0) at 
> ../iocore/eventsystem/I_IOBuffer.h:362
> #1  0x0050d151 in MIOBuffer::append_block_internal 
> (this=0x2aab38001130, b=0x2aab0c037200) at 
> ../iocore/eventsystem/P_IOBuffer.h:946
> #2  0x0050d39b in MIOBuffer::append_block (this=0x2aab38001130, 
> asize_index=15) at ../iocore/eventsystem/P_IOBuffer.h:986
> #3  0x0050d49b in MIOBuffer::add_block (this=0x2aab38001130) at 
> ../iocore/eventsystem/P_IOBuffer.h:994
> #4  0x0055cee2 in MIOBuffer::check_add_block (this=0x2aab38001130) at 
> ../iocore/eventsystem/P_IOBuffer.h:1002
> #5  0x0055d115 in MIOBuffer::write_avail (this=0x2aab38001130) at 
> ../iocore/eventsystem/P_IOBuffer.h:1048
> #6  0x006c18f3 in read_from_net (nh=0x2aaafca0d208, 
> vc=0x2aab1c009140, thread=0x2aaafca0a010) at UnixNetVConnection.cc:234
> #7  0x006c37bf in UnixNetVConnection::net_read_io 
> (this=0x2aab1c009140, nh=0x2aaafca0d208, lthread=0x2aaafca0a010) at 
> UnixNetVConnection.cc:816
> #8  0x006be392 in NetHandler::mainNetEvent (this=0x2aaafca0d208, 
> event=5, e=0x271d8e0) at UnixNet.cc:380
> #9  0x004f05c4 in Continuation::handleEvent (this=0x2aaafca0d208, 
> event=5, data=0x271d8e0) at ../iocore/eventsystem/I_Continuation.h:146
> #10 0x006e361e in EThread::process_event (this=0x2aaafca0a010, 
> e=0x271d8e0, calling_code=5) at UnixEThread.cc:142
> #11 0x006e3b13 in EThread::execute (this=0x2aaafca0a010) at 
> UnixEThread.cc:264
> #12 0x006e290b in spawn_thread_internal (a=0x2716400) at Thread.cc:88
> #13 0x003372c077e1 in start_thread () from /lib64/libpthread.so.0
> #14 0x0033728e68ed in clone () from /lib64/libc.so.6



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent

[Sudheer Vinukonda (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983363#comment-13983363
 ] 

Sudheer Vinukonda commented on TS-2750:
---

OK, the core dump happened again today with the same stack trace. Not sure, why 
it didnt happen over the weekend (perhaps, the weekend traffic mix might have 
been different to that of a weekday).

NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE: 
/lib64/libpthread.so.0(+0x329720f500)[0x2b900b3c8500]
/home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x5635b7]
/home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db60b]
/home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db8f3]
/home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4c73]
/home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c633b]
/home/y/bin/traffic_server[0x5d285c]
/home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d35fe]
/home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718e30]
/home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719b37]
/home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719d69]
/home/y/bin/traffic_server[0x5d0cb8]
/home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6edc07]
/home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6dde07]
/home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e5272]
/home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x71320f]
/home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x713bb3]
/home/y/bin/traffic_server[0x7125ba]
/lib64/libpthread.so.0(+0x3297207851)[0x2b900b3c0851]
/lib64/libc.so.6(clone+0x6d)[0x3296ee890d]


> Crash with SPDY on production environment in HttpAcceptCont::mainEvent
> --
>
> Key: TS-2750
> URL: https://issues.apache.org/jira/browse/TS-2750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Yunkai Zhang
>  Labels: SPDY_ATS
> Fix For: sometime
>
>
> After applying patches to ts-2742 (removing the ipv4 assert) and ts-2743 (w/ 
> a temporary fix still using the TS API, before a permanent fix is available), 
> noticed the below new core. 
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE: 
> /lib64/libpthread.so.0(+0x329720f500)[0x2b64e0a7a500]
> /home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x563337]
> /home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db38b]
> /home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db673]
> /home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4b53]
> /home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c621b]
> /home/y/bin/traffic_server[0x5d263c]
> /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d33de]
> /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718c10]
> /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719917]
> /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719b49]
> /home/y/bin/traffic_server[0x5d0aa8]
> /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed9e7]
> /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7EThread+0xf37)[0x6ddbe7]
> /home/y/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x6e5052]
> /home/y/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8f)[0x712fef]
> /home/y/bin/traffic_server(_ZN7EThread7executeEv+0x493)[0x713993]
> /home/y/bin/traffic_server[0x71239a]
> /lib64/libpthread.so.0(+0x3297207851)[0x2b64e0a72851]
> /lib64/libc.so.6(clone+0x6d)[0x3296ee890d]



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2740) Configuration settings to SPDY support in ATS

[Sudheer Vinukonda (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983347#comment-13983347
 ] 

Sudheer Vinukonda commented on TS-2740:
---

Thanks, Bryan - "yahoo" would work :=)

> Configuration settings to SPDY support in ATS
> -
>
> Key: TS-2740
> URL: https://issues.apache.org/jira/browse/TS-2740
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, SPDY
>Reporter: Sudheer Vinukonda
>  Labels: SPDY_ATS, yahoo
> Fix For: 5.0.0
>
>
> Would like to use this Jira to add the configuration settings that might be 
> useful to adapt SPDY on ATS
> 1. Currently, SPDY can only be turned on/off via the build with --enable-spdy 
> option. Would like to add a configuration control to turn on/off SPDY 
> capability (useful to troubleshoot production issues) when built with 
> --enable-spdy option.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2740) Configuration settings to SPDY support in ATS

[Bryan Call (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983337#comment-13983337
 ] 

Bryan Call commented on TS-2740:


[~sudheerv]

You can label it as "yahoo" and use the component SPDY.  You can also label it 
as "spdy" if you would like.  I don't think we should create project specific 
labels.


> Configuration settings to SPDY support in ATS
> -
>
> Key: TS-2740
> URL: https://issues.apache.org/jira/browse/TS-2740
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, SPDY
>Reporter: Sudheer Vinukonda
>  Labels: SPDY_ATS, yahoo
> Fix For: 5.0.0
>
>
> Would like to use this Jira to add the configuration settings that might be 
> useful to adapt SPDY on ATS
> 1. Currently, SPDY can only be turned on/off via the build with --enable-spdy 
> option. Would like to add a configuration control to turn on/off SPDY 
> capability (useful to troubleshoot production issues) when built with 
> --enable-spdy option.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TS-2740) Configuration settings to SPDY support in ATS

[Bryan Call (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Call updated TS-2740:
---

Labels: SPDY_ATS yahoo  (was: SPDY_ATS)

> Configuration settings to SPDY support in ATS
> -
>
> Key: TS-2740
> URL: https://issues.apache.org/jira/browse/TS-2740
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, SPDY
>Reporter: Sudheer Vinukonda
>  Labels: SPDY_ATS, yahoo
> Fix For: 5.0.0
>
>
> Would like to use this Jira to add the configuration settings that might be 
> useful to adapt SPDY on ATS
> 1. Currently, SPDY can only be turned on/off via the build with --enable-spdy 
> option. Would like to add a configuration control to turn on/off SPDY 
> capability (useful to troubleshoot production issues) when built with 
> --enable-spdy option.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2758) unable to get file descriptor from transaction close

[James Peach (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983323#comment-13983323
 ] 

James Peach commented on TS-2758:
-

{{TSHttpSsnClientFdGet}} fails from both {{TS_EVENT_HTTP_TXN_CLOSE}} and from 
{{TS_EVENT_HTTP_SSN_CLOSE}}.

I'm not sure whether the {{TS_EVENT_HTTP_TXN_CLOSE}} case is fixable in 
general; I think there are times when the transaction may logically continue 
even though the client has disconnected. There are also times when the client 
is disconnected early, e.g. in {{HttpSM::tunnel_handler_ua}}.

{{TS_EVENT_HTTP_SSN_CLOSE}} seems a lot more tractable.

> unable to get file descriptor from transaction close
> 
>
> Key: TS-2758
> URL: https://issues.apache.org/jira/browse/TS-2758
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: James Peach
> Fix For: sometime
>
>
> While testing the {{tcpinfo}} plugin, I found that {{TSHttpSsnClientFdGet}} 
> fails from the {{TS_HTTP_TXN_CLOSE_HOOK}}. It would be really useful for the 
> {{tcpinfo}} plugin to be able to collect statistics at the end of 
> transactions and sessions.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2740) Configuration settings to SPDY support in ATS

[Sudheer Vinukonda (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983297#comment-13983297
 ] 

Sudheer Vinukonda commented on TS-2740:
---

Leif -

I understand that there's a Component field that can group SPDY tickets. 
However, we would like to have a way of grouping tickets opened by our team 
(including myself, Wei Sun, bcall etc) working on SPDY adaption in our 
production environment. This is for purely for our internal tracking purposes. 
Also, I don't have a particularly strong preference towards using a separate 
Label - as a matter of fact, we initially used the same SPDY_ATS tag as part of 
the ticket summary/synopsis, but, jpeach recommended to use the Label field 
instead. For tracking the tickets opened by our team, either option would work, 
and I'd be happy to follow any other suggestions you may have. Thanks for the 
understanding.


> Configuration settings to SPDY support in ATS
> -
>
> Key: TS-2740
> URL: https://issues.apache.org/jira/browse/TS-2740
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, SPDY
>Reporter: Sudheer Vinukonda
>  Labels: SPDY_ATS
> Fix For: 5.0.0
>
>
> Would like to use this Jira to add the configuration settings that might be 
> useful to adapt SPDY on ATS
> 1. Currently, SPDY can only be turned on/off via the build with --enable-spdy 
> option. Would like to add a configuration control to turn on/off SPDY 
> capability (useful to troubleshoot production issues) when built with 
> --enable-spdy option.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Updated] (TS-2740) Configuration settings to SPDY support in ATS

[Sudheer Vinukonda (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-2740?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Sudheer Vinukonda updated TS-2740:
--

Labels: SPDY_ATS  (was: )

> Configuration settings to SPDY support in ATS
> -
>
> Key: TS-2740
> URL: https://issues.apache.org/jira/browse/TS-2740
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, SPDY
>Reporter: Sudheer Vinukonda
>  Labels: SPDY_ATS
> Fix For: 5.0.0
>
>
> Would like to use this Jira to add the configuration settings that might be 
> useful to adapt SPDY on ATS
> 1. Currently, SPDY can only be turned on/off via the build with --enable-spdy 
> option. Would like to add a configuration control to turn on/off SPDY 
> capability (useful to troubleshoot production issues) when built with 
> --enable-spdy option.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent

[Sudheer Vinukonda (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983248#comment-13983248
 ] 

Sudheer Vinukonda commented on TS-2750:
---

(gdb) up
#1  HttpAcceptCont::mainEvent (this=0x40dead0, event=, 
data=0x2ab87e071948) at HttpAcceptCont.cc:62
62  HttpClientSession *new_session = 
THREAD_ALLOC_INIT(httpClientSessionAllocator, netvc->thread);
(gdb) up
#2  0x004db5cb in handleEvent (this=0x2ab87e071750) at 
../iocore/eventsystem/I_Continuation.h:146
146 return (this->*handler) (event, data);
(gdb) up
#3  PluginVCCore::state_send_accept (this=0x2ab87e071750) at PluginVC.cc:1118
1118connect_to->handleEvent(NET_EVENT_ACCEPT, &passive_vc);
(gdb) up
#4  0x004db8b3 in PluginVCCore::connect (this=0x2ab87e071750) at 
PluginVC.cc:1064
1064  state_send_accept(EVENT_IMMEDIATE, NULL);
(gdb) up
#5  0x004b4b93 in TSHttpConnectWithProtoStack (addr=0x2ab870a46134, 
proto_stack=4096) at InkAPI.cc:6114
6114PluginVC *return_vc = new_pvc->connect();
(gdb) up
#6  0x004c626a in httpConnect (this=0x2ab870a45f90) at FetchSM.cc:73
73http_vc = TSHttpConnectWithProtoStack(&_addr.sa, proto_stack);
(gdb) up
#7  FetchSM::ext_lanuch (this=0x2ab870a45f90) at FetchSM.cc:523
523 FetchSM::ext_write_data(const void *data, size_t len)
(gdb) up
#8  0x005d287c in spdy_fetcher_launch (req=0x2ab85877bc50, 
method=TS_FETCH_METHOD_GET) at SpdyCallbacks.cc:203
203 
(gdb) up
#9  0x005d361e in spdy_process_syn_stream_frame (session=, type=, frame=, 
user_data=0x2ab85559bfe0) at SpdyCallbacks.cc:288
288  || !req->version.size() || !req->host.size()) {
(gdb) print req
$2 = (SpdyRequest *) 0x2ab85877bc50
(gdb) print *req
$3 = {event = 0, spdy_sm = 0x2ab85559bfe0, stream_id = 129, start_time = 
1398703653423499321, fetch_sm = 0x2ab870a45f90, has_submitted_data = false, 
need_resume_data = false, fetch_data_len = 0, 
  delta_window_size = 0, fetch_body_completed = false, headers = std::vector of 
length 9, capacity 16 = {{first = ":host", second = "sp1.yimg.com"}, {first = 
":method", second = "GET"}, {first = 
":path", second = "/ib/th?id=HN.608041114380075749&pid=15.1"}, {first = 
":scheme", second = "https"}, {first = ":version", second = "HTTP/1.1"}, {first 
= "accept", second = 
"image/png,image/*;q=0.8,*/*;q=0.5"}, {first = "accept-language", second = 
"en-US,en;q=0.5"}, {first = "referer", second = 

"https://images.search.yahoo.com/search/images;_ylt=A0SO8ocUhl5TwAsAHIFXNyoA;_ylu=X3oDMTB0NTF2ZWo3BHNlYwNzYwRjb2xvA2dxMQR2dGlkA1ZJUDA0OV8x?_adv_prop=image&fr=yfp-t-901-s&va=stellar+jay"},
 {
  first = "user-agent", second = "Mozilla/5.0 (Windows NT 6.1; WOW64; 
rv:28.0) Gecko/20100101 Firefox/28.0"}}, url = 
"https://sp1.yimg.com/ib/th?id=HN.608041114380075749&pid=15.1";, host = 
"sp1.yimg.com", path = "/ib/th?id=HN.608041114380075749&pid=15.1", scheme = 
"https", method = "GET", version = "HTTP/1.1", recv_md5 = {A = 1732584193, B = 
4023233417, C = 2562383102, 
D = 271733878, Nl = 0, Nh = 0, data = {0 }, num = 0}}



> Crash with SPDY on production environment in HttpAcceptCont::mainEvent
> --
>
> Key: TS-2750
> URL: https://issues.apache.org/jira/browse/TS-2750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Yunkai Zhang
>  Labels: SPDY_ATS
> Fix For: sometime
>
>
> After applying patches to ts-2742 (removing the ipv4 assert) and ts-2743 (w/ 
> a temporary fix still using the TS API, before a permanent fix is available), 
> noticed the below new core. 
> NOTE: Traffic Server received Sig 11: Segmentation fault
> /home/y/bin/traffic_server - STACK TRACE: 
> /lib64/libpthread.so.0(+0x329720f500)[0x2b64e0a7a500]
> /home/y/bin/traffic_server(_ZN14HttpAcceptCont9mainEventEiPv+0x147)[0x563337]
> /home/y/bin/traffic_server(_ZN12PluginVCCore17state_send_acceptEiPv+0x9b)[0x4db38b]
> /home/y/bin/traffic_server(_ZN12PluginVCCore7connectEv+0x23)[0x4db673]
> /home/y/bin/traffic_server(TSHttpConnectWithProtoStack+0x83)[0x4b4b53]
> /home/y/bin/traffic_server(_ZN7FetchSM10ext_lanuchEv+0x3b)[0x4c621b]
> /home/y/bin/traffic_server[0x5d263c]
> /home/y/bin/traffic_server(_Z26spdy_on_ctrl_recv_callbackP15spdylay_session18spdylay_frame_typeP13spdylay_framePv+0x6fe)[0x5d33de]
> /home/y/bin/traffic_server(spdylay_session_on_syn_stream_received+0xe0)[0x718c10]
> /home/y/bin/traffic_server(spdylay_session_mem_recv+0xb47)[0x719917]
> /home/y/bin/traffic_server(spdylay_session_recv+0x49)[0x719b49]
> /home/y/bin/traffic_server[0x5d0aa8]
> /home/y/bin/traffic_server(_ZN18UnixNetVConnection19readSignalAndUpdateEi+0x27)[0x6ed9e7]
> /home/y/bin/traffic_server(_ZN17SSLNetVConnection11net_read_ioEP10NetHandlerP7E

[jira] [Commented] (TS-2750) Crash with SPDY on production environment in HttpAcceptCont::mainEvent

[Sudheer Vinukonda (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2750?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983245#comment-13983245
 ] 

Sudheer Vinukonda commented on TS-2750:
---

Strangely, I've not been able to reproduce this core since Friday evening. 
There hasn't been any changes on the ATS version that I have been using, but, 
it looks to be running fine since Friday. Will continue to monitor and report 
back if I see it again.

In the mean time, below's the stack trace from gdb for this core from Friday 
morning.

#0  thread_alloc_init (this=0x40dead0, event=, data=0x2ab87e071948) at 
../../iocore/eventsystem/I_ProxyAllocator.h:71
71  memcpy((void *) v, (void *) &a.proto.typeObject, sizeof(C));
Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.132.el6.x86_64 
gmp-4.3.1-7.el6_2.2.x86_64 hwloc-1.5-1.el6.x86_64 
keyutils-libs-1.4-4.el6.x86_64 krb5-libs-1.10.3-10.el6_4.6.x86_64 
libattr-2.4.44-7.el6.x86_64 libcap-2.16-5.5.el6.x86_64 
libcom_err-1.41.12-18.el6.x86_64 libgcc-4.4.7-4.el6.x86_64 
libselinux-2.0.94-5.3.el6_4.1.x86_64 libstdc++-4.4.7-4.el6.x86_64 
libxml2-2.7.6-14.el6.x86_64 nss-softokn-freebl-3.14.3-9.el6.x86_64 
numactl-2.0.7-8.el6.x86_64 openssl-1.0.1e-16.el6_5.4.x86_64 
pciutils-libs-3.1.10-2.el6.x86_64 pcre-7.8-6.el6.x86_64 tcl-8.5.7-6.el6.x86_64 
xz-libs-4.999.9-0.3.beta.20091007git.el6.x86_64 zlib-1.2.3-29.el6.x86_64
(gdb) bt
#0  thread_alloc_init (this=0x40dead0, event=, data=0x2ab87e071948) at 
../../iocore/eventsystem/I_ProxyAllocator.h:71
#1  HttpAcceptCont::mainEvent (this=0x40dead0, event=, 
data=0x2ab87e071948) at HttpAcceptCont.cc:62
#2  0x004db5cb in handleEvent (this=0x2ab87e071750) at 
../iocore/eventsystem/I_Continuation.h:146
#3  PluginVCCore::state_send_accept (this=0x2ab87e071750) at PluginVC.cc:1118
#4  0x004db8b3 in PluginVCCore::connect (this=0x2ab87e071750) at 
PluginVC.cc:1064
#5  0x004b4b93 in TSHttpConnectWithProtoStack (addr=0x2ab870a46134, 
proto_stack=4096) at InkAPI.cc:6114
#6  0x004c626a in httpConnect (this=0x2ab870a45f90) at FetchSM.cc:73
#7  FetchSM::ext_lanuch (this=0x2ab870a45f90) at FetchSM.cc:523
#8  0x005d287c in spdy_fetcher_launch (req=0x2ab85877bc50, 
method=TS_FETCH_METHOD_GET) at SpdyCallbacks.cc:203
#9  0x005d361e in spdy_process_syn_stream_frame (session=, type=, frame=, 
user_data=0x2ab85559bfe0) at SpdyCallbacks.cc:288
#10 spdy_on_ctrl_recv_callback (session=, type=, frame=, user_data=0x2ab85559bfe0) at 
SpdyCallbacks.cc:326
#11 0x00718e50 in spdylay_session_on_syn_stream_received 
(session=0x2ab87d649060, frame=0x2ab79ce509e0) at spdylay_session.c:1782
#12 0x00719b57 in spdylay_session_process_ctrl_frame 
(session=0x2ab87d649060, in=0x2ab79ce50a50 "\200\003", inlen=) at spdylay_session.c:2246
#13 spdylay_session_mem_recv (session=0x2ab87d649060, in=0x2ab79ce50a50 
"\200\003", inlen=) at spdylay_session.c:2805
#14 0x00719d89 in spdylay_session_recv (session=0x2ab87d649060) at 
spdylay_session.c:2828
#15 0x005d0ce8 in spdy_process_read (contp=, 
event=TS_EVENT_VCONN_READ_READY, edata=) at SpdySM.cc:263
#16 spdy_default_handler (contp=, 
event=TS_EVENT_VCONN_READ_READY, edata=) at SpdySM.cc:233
#17 0x006edc27 in handleEvent (this=0x2ab8c821fe10, event=) at ../../iocore/eventsystem/I_Continuation.h:146
#18 read_signal_and_update (this=0x2ab8c821fe10, event=) 
at UnixNetVConnection.cc:216
#19 UnixNetVConnection::readSignalAndUpdate (this=0x2ab8c821fe10, event=) at UnixNetVConnection.cc:998
#20 0x006dde27 in SSLNetVConnection::net_read_io (this=0x2ab8c821fe10, 
nh=0x2ab79b540c10, lthread=0x2ab79b53d010) at SSLNetVConnection.cc:294
#21 0x006e5292 in NetHandler::mainNetEvent (this=0x2ab79b540c10, 
event=, e=) at UnixNet.cc:384
#22 0x0071322f in handleEvent (this=0x2ab79b53d010, e=0x3053c50, 
calling_code=5) at I_Continuation.h:146
#23 EThread::process_event (this=0x2ab79b53d010, e=0x3053c50, calling_code=5) 
at UnixEThread.cc:145
#24 0x00713bd3 in EThread::execute (this=0x2ab79b53d010) at 
UnixEThread.cc:269
#25 0x007125da in spawn_thread_internal (a=0x3308ef0) at Thread.cc:88
#26 0x2ab786c6f851 in __free_tcb () from /lib64/libpthread.so.0
#27 0x in ?? ()




> Crash with SPDY on production environment in HttpAcceptCont::mainEvent
> --
>
> Key: TS-2750
> URL: https://issues.apache.org/jira/browse/TS-2750
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Sudheer Vinukonda
>Assignee: Yunkai Zhang
>  Labels: SPDY_ATS
> Fix For: sometime
>
>
> After applying patches to ts-2742 (removing the ipv4 assert) and ts-2743 (w/ 
> a temporary fix still using the TS API, before a permanent fix is available), 
> noticed the be

[jira] [Commented] (TS-2497) Failed post results in tunnel buffers being returned to freelist prematurely

[Shaun McGinnity (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983192#comment-13983192
 ] 

Shaun McGinnity commented on TS-2497:
-

I've applied this patch to 3.2.X but I am seeing memory growth from unreleased 
IO Buffers. Is there another patch that needs to be applied along with this?

I am running a test against a server that deliberately closes the connection 
before reading the full post content. Polling the memory statistics every 30s:

Apr 28 17:41:10 - INFO -   0 |  0 |  32768 
| memory/ioBufAllocator[8]
Apr 28 17:41:40 - INFO - 6291456 |5472256 |  32768 
| memory/ioBufAllocator[8]
Apr 28 17:42:10 - INFO -11534336 |   10616832 |  32768 
| memory/ioBufAllocator[8]
Apr 28 17:42:39 - INFO -18874368 |   18022400 |  32768 
| memory/ioBufAllocator[8]
Apr 28 17:43:10 - INFO -24117248 |   22970368 |  32768 
| memory/ioBufAllocator[8]
Apr 28 17:43:40 - INFO -30408704 |   30048256 |  32768 
| memory/ioBufAllocator[8]
Apr 28 17:44:10 - INFO -36700160 |   35454976 |  32768 
| memory/ioBufAllocator[8]
Apr 28 17:44:40 - INFO -42991616 |   41451520 |  32768 
| memory/ioBufAllocator[8]
Apr 28 17:45:10 - INFO -49283072 |   48103424 |  32768 
| memory/ioBufAllocator[8]
Apr 28 17:45:40 - INFO -54525952 |   53444608 |  32768 
| memory/ioBufAllocator[8]
Apr 28 17:46:09 - INFO -61865984 |   60358656 |  32768 
| memory/ioBufAllocator[8]
Apr 28 17:46:40 - INFO -61865984 |   61472768 |  32768 
| memory/ioBufAllocator[8]


> Failed post results in tunnel buffers being returned to freelist prematurely
> 
>
> Key: TS-2497
> URL: https://issues.apache.org/jira/browse/TS-2497
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Brian Geffon
>Assignee: Brian Geffon
> Fix For: 4.2.0
>
>
> When a post fails to an origin server either the server died or the server 
> returned a response without reading all of the post data, in either case, TS 
> will destroy buffers too early. This normally does not result in a crash 
> because the MIOBuffers are returned to the freelist and only with sufficient 
> load will the race happen causing a crash. Additionally, even if a crash 
> doesn't happen you might have data corruption across post requests from the 
> buffers being used after being returned to the freelist.
> Thanks to Thomas Jackson for help reproducing and resolving this bug.
> An example stack trace, while we've seen other crashes in write_avail too.
> #0  0x004eff14 in IOBufferBlock::read_avail (this=0x0) at 
> ../iocore/eventsystem/I_IOBuffer.h:362
> #1  0x0050d151 in MIOBuffer::append_block_internal 
> (this=0x2aab38001130, b=0x2aab0c037200) at 
> ../iocore/eventsystem/P_IOBuffer.h:946
> #2  0x0050d39b in MIOBuffer::append_block (this=0x2aab38001130, 
> asize_index=15) at ../iocore/eventsystem/P_IOBuffer.h:986
> #3  0x0050d49b in MIOBuffer::add_block (this=0x2aab38001130) at 
> ../iocore/eventsystem/P_IOBuffer.h:994
> #4  0x0055cee2 in MIOBuffer::check_add_block (this=0x2aab38001130) at 
> ../iocore/eventsystem/P_IOBuffer.h:1002
> #5  0x0055d115 in MIOBuffer::write_avail (this=0x2aab38001130) at 
> ../iocore/eventsystem/P_IOBuffer.h:1048
> #6  0x006c18f3 in read_from_net (nh=0x2aaafca0d208, 
> vc=0x2aab1c009140, thread=0x2aaafca0a010) at UnixNetVConnection.cc:234
> #7  0x006c37bf in UnixNetVConnection::net_read_io 
> (this=0x2aab1c009140, nh=0x2aaafca0d208, lthread=0x2aaafca0a010) at 
> UnixNetVConnection.cc:816
> #8  0x006be392 in NetHandler::mainNetEvent (this=0x2aaafca0d208, 
> event=5, e=0x271d8e0) at UnixNet.cc:380
> #9  0x004f05c4 in Continuation::handleEvent (this=0x2aaafca0d208, 
> event=5, data=0x271d8e0) at ../iocore/eventsystem/I_Continuation.h:146
> #10 0x006e361e in EThread::process_event (this=0x2aaafca0a010, 
> e=0x271d8e0, calling_code=5) at UnixEThread.cc:142
> #11 0x006e3b13 in EThread::execute (this=0x2aaafca0a010) at 
> UnixEThread.cc:264
> #12 0x006e290b in spawn_thread_internal (a=0x2716400) at Thread.cc:88
> #13 0x003372c077e1 in start_thread () from /lib64/libpthread.so.0
> #14 0x0033728e68ed in clone () from /lib64/libc.so.6



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (TS-2753) Add SPDY statistics

[Sudheer Vinukonda (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983056#comment-13983056
 ] 

Sudheer Vinukonda edited comment on TS-2753 at 4/28/14 2:50 PM:


Leif - 

I understand that there's a Component field that can group SPDY tickets. 
However, we would like to have a way of grouping tickets opened by our team 
(including myself, Wei Sun, bcall etc) working on SPDY adaption in our 
production environment. This is for purely for our internal tracking purposes. 
Also, I don't have a particularly strong preference towards using a separate 
Label - as a matter of fact, we initially used the same SPDY_ATS tag as part of 
the ticket summary/synopsis, but, jpeach recommended to use the Label field 
instead. For tracking the tickets opened by our team, either option would work, 
and I'd be happy to follow any other suggestions you may have. Thanks for the 
understanding.


was (Author: sudheerv):
Leif - 

I understand that there's a Component field that can group SPDY tickets. 
However, we would like to have a way of grouping the tickets opened by our team 
(including myself, Wei Sun, bcall etc) working on SPDY adaption in our 
production environment. This is for purely for our internal tracking purposes. 
Also, I don't have a particularly strong preference towards using a separate 
Label - as a matter of fact, we initially used the same SPDY_ATS tag as part of 
the ticket summary/synopsis, but, jpeach recommended to use the Label field 
instead. For tracking the tickets opened by our team, either option would work, 
and I'd be happy to follow any other suggestions you may have. Thanks for the 
understanding.

> Add SPDY statistics
> ---
>
> Key: TS-2753
> URL: https://issues.apache.org/jira/browse/TS-2753
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SPDY
>Reporter: Wei Sun
>  Labels: SPDY_ATS
> Fix For: 5.0.0
>
>
> Adding stats to spdy helps monitoring and troubleshooting, it would be good 
> to define and add the general information like the HTTP stats in 
> proxy/http/HttpConfig.h and spdy specific stats as well.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2753) Add SPDY statistics

[Sudheer Vinukonda (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2753?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983056#comment-13983056
 ] 

Sudheer Vinukonda commented on TS-2753:
---

Leif - 

I understand that there's a Component field that can group SPDY tickets. 
However, we would like to have a way of grouping the tickets opened by our team 
(including myself, Wei Sun, bcall etc) working on SPDY adaption in our 
production environment. This is for purely for our internal tracking purposes. 
Also, I don't have a particularly strong preference towards using a separate 
Label - as a matter of fact, we initially used the same SPDY_ATS tag as part of 
the ticket summary/synopsis, but, jpeach recommended to use the Label field 
instead. For tracking the tickets opened by our team, either option would work, 
and I'd be happy to follow any other suggestions you may have. Thanks for the 
understanding.

> Add SPDY statistics
> ---
>
> Key: TS-2753
> URL: https://issues.apache.org/jira/browse/TS-2753
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SPDY
>Reporter: Wei Sun
>  Labels: SPDY_ATS
> Fix For: 5.0.0
>
>
> Adding stats to spdy helps monitoring and troubleshooting, it would be good 
> to define and add the general information like the HTTP stats in 
> proxy/http/HttpConfig.h and spdy specific stats as well.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2752) Custom logging field accelerator_id (xid) not recognized in the master ats

[Sudheer Vinukonda (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13983050#comment-13983050
 ] 

Sudheer Vinukonda commented on TS-2752:
---

Leif - Thanks for the additional details. We don't really need the XID field as 
well. It was just part of our default custom logging configuration in 4.0.2 and 
obviously didn't work on the master copy. Just opened this ticket to confirm if 
there's anything that we might be doing incorrect.

> Custom logging field accelerator_id (xid) not recognized in the master ats
> --
>
> Key: TS-2752
> URL: https://issues.apache.org/jira/browse/TS-2752
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging, SPDY
>Reporter: Sudheer Vinukonda
>  Labels: SPDY_ATS
>
> While testing SPDY (using ats from the master repo) on a production host, i 
> noticed that the below format in our logs_xml.config (that works on 4.0) 
> doesn't work anymore:
> 
>   
>% % %/% % % % 
> % %/% % % % \"%<{User-Agent}cqh>\""/>
> 
> It just outputs the below line:
> [Apr 24 20:44:22.724] {0x7fd73eeba7e0} NOTE: There are more field markers 
> than fields; cannot process log entry
> Upon some investigation, it looks like the field % is not supported in 
> the master code anymore. Although, we don't really need this field, wanted to 
> understand why/how this field got removed in the master. 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-562) Custom paths for zlib, openssl, pcre don't work if in non-standard locations without adding --rpath

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13982972#comment-13982972
 ] 

ASF GitHub Bot commented on TS-562:
---

Github user zwoop commented on the pull request:

https://github.com/apache/trafficserver/pull/75#issuecomment-41553927
  
A long time ago, TS-562, we made some changes to (I think?) properly use 
-rpath with the libtool macros. See commit 
449a4e4d83a6665a25371deca36b29ba7f4359df.

I don't know what has happened since then.


> Custom paths for zlib, openssl, pcre don't work if in non-standard locations 
> without adding --rpath
> ---
>
> Key: TS-562
> URL: https://issues.apache.org/jira/browse/TS-562
> Project: Traffic Server
>  Issue Type: Improvement
>Affects Versions: 2.1.5
> Environment: Linux
>Reporter: Marcus Clyne
>Assignee: Leif Hedstrom
>Priority: Minor
> Fix For: 2.1.9
>
>
> When compiling with custom paths for OpenSSL, PCRE, Zlib etc where the paths 
> are in non-standard locations, even if the configure script passes, the 
> libraries may not be linked if their lib path is not in the standard path 
> checked by ld.
> The libraries can be found if extra linker options are passed like 
> -Wl,--rpath=/path/to/lib/dir, but it would make sense to add this 
> automatically on systems that support it if the path is passed to the 
> configure script using --with-openssl=... etc.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Commented] (TS-2749) rfc5861 errors

[Faysal Banna (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13982871#comment-13982871
 ] 

Faysal Banna commented on TS-2749:
--

Hi 
This is plugin rfc5861

Regards



> rfc5861  errors 
> 
>
> Key: TS-2749
> URL: https://issues.apache.org/jira/browse/TS-2749
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, Plugins
>Reporter: Faysal Banna
>
> Good Day.
> I been playing around with Plugins and found this one to cause some errors 
> which illustrated below.
> FATAL: InkAPI.cc:2669: failed assert `sdk_sanity_check_mbuffer(bufp) == 
> TS_SUCCESS` 
> /usr/local/bin/traffic_server - STACK TRACE:  
> /usr/local/lib/libtsutil.so.4(+0x1ecf7)[0x2aafcbbddcf7] 
> /usr/local/lib/libtsutil.so.4(+0x1dc3f)[0x2aafcbbdcc3f] 
> /usr/local/bin/traffic_server(TSMimeHdrFieldFind+0x2f)[0x4ae1bf] 
> /usr/local/libexec/trafficserver/rfc5861.so(+0x301a)[0x2aafd6c8001a] 
> /usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x150)[0x6adda0]
>  
> /usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x6f3)[0x6ae833] 
> /usr/local/bin/traffic_server[0x6ad6da] 
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7f6e)[0x2aafccff6f6e] 
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2aafcdd289cd] 
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr/local' 
>  which after disabling rfc5861 plugin these errors didn't occur anymore
> CoreDumps and stack traces are available for debugging if needed 
> much regards 



--
This message was sent by Atlassian JIRA
(v6.2#6252)

[jira] [Comment Edited] (TS-2749) rfc5861 errors

[Faysal Banna (JIRA)]

[ 
https://issues.apache.org/jira/browse/TS-2749?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13982871#comment-13982871
 ] 

Faysal Banna edited comment on TS-2749 at 4/28/14 9:35 AM:
---

Hi 
This is plugin rfc5861
(stale-while-revalidate)
Regards




was (Author: degreane):
Hi 
This is plugin rfc5861

Regards



> rfc5861  errors 
> 
>
> Key: TS-2749
> URL: https://issues.apache.org/jira/browse/TS-2749
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache, Plugins
>Reporter: Faysal Banna
>
> Good Day.
> I been playing around with Plugins and found this one to cause some errors 
> which illustrated below.
> FATAL: InkAPI.cc:2669: failed assert `sdk_sanity_check_mbuffer(bufp) == 
> TS_SUCCESS` 
> /usr/local/bin/traffic_server - STACK TRACE:  
> /usr/local/lib/libtsutil.so.4(+0x1ecf7)[0x2aafcbbddcf7] 
> /usr/local/lib/libtsutil.so.4(+0x1dc3f)[0x2aafcbbdcc3f] 
> /usr/local/bin/traffic_server(TSMimeHdrFieldFind+0x2f)[0x4ae1bf] 
> /usr/local/libexec/trafficserver/rfc5861.so(+0x301a)[0x2aafd6c8001a] 
> /usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x150)[0x6adda0]
>  
> /usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x6f3)[0x6ae833] 
> /usr/local/bin/traffic_server[0x6ad6da] 
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x7f6e)[0x2aafccff6f6e] 
> /lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x2aafcdd289cd] 
> [E. Mgmt] log ==> [TrafficManager] using root directory '/usr/local' 
>  which after disabling rfc5861 plugin these errors didn't occur anymore
> CoreDumps and stack traces are available for debugging if needed 
> much regards 



--
This message was sent by Atlassian JIRA
(v6.2#6252)