[jira] [Created] (TS-3026) SPDY forwarding Accept-Encoding headers for Firefox
Scott Beardsley created TS-3026: --- Summary: SPDY forwarding Accept-Encoding headers for Firefox Key: TS-3026 URL: https://issues.apache.org/jira/browse/TS-3026 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Scott Beardsley Firefox is claiming to be sending the Accept-Encoding header (specifically Accept-Encoding: gzip, deflate) but somewhere it appears to be dropped. I don't see it show up in the logs with http.* debug on. Here is what TS sees: + Incoming Request + -- State Machine Id: 0 GET http://origin.example.com/ HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-language: en-US,en;q=0.5 cookie: cookies dnt: 1 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0 Host: example.com -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3026) SPDY forwarding Accept-Encoding headers for Firefox
[ https://issues.apache.org/jira/browse/TS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Beardsley updated TS-3026: Attachment: Screen Shot 2014-08-20 at 1.06.42 AM.png Screen shot of firebug claiming to send the Accept-Encoding header. Firefox 32.0 SPDY forwarding Accept-Encoding headers for Firefox --- Key: TS-3026 URL: https://issues.apache.org/jira/browse/TS-3026 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Scott Beardsley Attachments: Screen Shot 2014-08-20 at 1.06.42 AM.png Firefox is claiming to be sending the Accept-Encoding header (specifically Accept-Encoding: gzip, deflate) but somewhere it appears to be dropped. I don't see it show up in the logs with http.* debug on. Here is what TS sees: + Incoming Request + -- State Machine Id: 0 GET http://origin.example.com/ HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-language: en-US,en;q=0.5 cookie: cookies dnt: 1 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0 Host: example.com -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3026) SPDY not forwarding Accept-Encoding headers for Firefox
[ https://issues.apache.org/jira/browse/TS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Scott Beardsley updated TS-3026: Summary: SPDY not forwarding Accept-Encoding headers for Firefox (was: SPDY forwarding Accept-Encoding headers for Firefox) SPDY not forwarding Accept-Encoding headers for Firefox --- Key: TS-3026 URL: https://issues.apache.org/jira/browse/TS-3026 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Scott Beardsley Attachments: Screen Shot 2014-08-20 at 1.06.42 AM.png Firefox is claiming to be sending the Accept-Encoding header (specifically Accept-Encoding: gzip, deflate) but somewhere it appears to be dropped. I don't see it show up in the logs with http.* debug on. Here is what TS sees: + Incoming Request + -- State Machine Id: 0 GET http://origin.example.com/ HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-language: en-US,en;q=0.5 cookie: cookies dnt: 1 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0 Host: example.com -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3026) SPDY not forwarding Accept-Encoding headers for Firefox
[
https://issues.apache.org/jira/browse/TS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103617#comment-14103617
]
Scott Beardsley commented on TS-3026:
-
The Accept-Encoding header doesn't appear to be showing up in the spdy debug
logging...
[Aug 20 08:33:01.744] Server {0x2b3707d4c700} DEBUG: (spdy) RECV SYN_STREAM
(sm_id:1, stream_id:1, flag:1, length:3079)
[Aug 20 08:33:01.744] Server {0x2b3707d4c700} DEBUG: (spdy) :host:
example.com
[Aug 20 08:33:01.744] Server {0x2b3707d4c700} DEBUG: (spdy) :method: GET
[Aug 20 08:33:01.744] Server {0x2b3707d4c700} DEBUG: (spdy) :path: /
[Aug 20 08:33:01.744] Server {0x2b3707d4c700} DEBUG: (spdy) :scheme: https
[Aug 20 08:33:01.744] Server {0x2b3707d4c700} DEBUG: (spdy) :version:
HTTP/1.1
[Aug 20 08:33:01.744] Server {0x2b3707d4c700} DEBUG: (spdy) accept:
text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
[Aug 20 08:33:01.744] Server {0x2b3707d4c700} DEBUG: (spdy)
accept-language: en-US,en;q=0.5
[Aug 20 08:33:01.744] Server {0x2b3707d4c700} DEBUG: (spdy) cookie: cookie
[Aug 20 08:33:01.744] Server {0x2b3707d4c700} DEBUG: (spdy) dnt: 1
[Aug 20 08:33:01.744] Server {0x2b3707d4c700} DEBUG: (spdy) user-agent:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101
Firefox/32.0
[Aug 20 08:33:01.744] Server {0x2b3707d4c700} DEBUG: (spdy) Request[1:1]
https://example.com/
SPDY not forwarding Accept-Encoding headers for Firefox
---
Key: TS-3026
URL: https://issues.apache.org/jira/browse/TS-3026
Project: Traffic Server
Issue Type: Bug
Components: SPDY
Reporter: Scott Beardsley
Attachments: Screen Shot 2014-08-20 at 1.06.42 AM.png
Firefox is claiming to be sending the Accept-Encoding header (specifically
Accept-Encoding: gzip, deflate) but somewhere it appears to be dropped. I
don't see it show up in the logs with http.* debug on. Here is what TS sees:
+ Incoming Request +
-- State Machine Id: 0
GET
http://origin.example.com/
HTTP/1.1
accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
accept-language: en-US,en;q=0.5
cookie: cookies
dnt: 1
user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0)
Gecko/20100101 Firefox/32.0
Host: example.com
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3026) SPDY not forwarding Accept-Encoding headers for Firefox
[ https://issues.apache.org/jira/browse/TS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103628#comment-14103628 ] Scott Beardsley commented on TS-3026: - Looks like this is a known issue with Firefox... see also this: https://support.mozilla.org/en-US/questions/995095 and this nginx ticket: http://trac.nginx.org/nginx/ticket/542 Perhaps we should assume the gzip accept-encoding when spdy is being used (like nginx is apparently suggesting)? Might be good to have some content-type checks also. SPDY not forwarding Accept-Encoding headers for Firefox --- Key: TS-3026 URL: https://issues.apache.org/jira/browse/TS-3026 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Scott Beardsley Attachments: Screen Shot 2014-08-20 at 1.06.42 AM.png Firefox is claiming to be sending the Accept-Encoding header (specifically Accept-Encoding: gzip, deflate) but somewhere it appears to be dropped. I don't see it show up in the logs with http.* debug on. Here is what TS sees: + Incoming Request + -- State Machine Id: 0 GET http://origin.example.com/ HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-language: en-US,en;q=0.5 cookie: cookies dnt: 1 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0 Host: example.com -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3025) Segmentation fault
[
https://issues.apache.org/jira/browse/TS-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103744#comment-14103744
]
Wei Sun commented on TS-3025:
-
Similar stack trace with 5.0.x after enabling spdy.
{code}
(gdb) bt
#0 0x00751cac in EThread::is_event_type (this=0x0, et=1) at
UnixEThread.cc:122
#1 0x0072f908 in UnixNetProcessor::connect_re_internal
(this=0x1018780, cont=0x2b0e67ab0b20, target=0x2b0e67ab11c8,
opt=0x2b0bae942650, servername=0x2b0ef61b2f10 mkfrm.zenfs.com)
at UnixNetProcessor.cc:249
#2 0x0051d367 in NetProcessor::connect_re (this=0x1018780,
cont=0x2b0e67ab0b20, addr=0x2b0e67ab11c8, opts=0x2b0bae942650,
servername=0x2b0ef61b2f10 mkfrm.zenfs.com)
at ../iocore/net/P_UnixNetProcessor.h:87
#3 0x005d6248 in HttpSM::do_http_server_open (this=0x2b0e67ab0b20,
raw=false) at HttpSM.cc:4653
#4 0x005dd871 in HttpSM::set_next_state (this=0x2b0e67ab0b20) at
HttpSM.cc:6988
#5 0x005dcc9c in HttpSM::call_transact_and_set_next_state
(this=0x2b0e67ab0b20, f=0x5f5604
HttpTransact::HandleResponse(HttpTransact::State*)) at HttpSM.cc:6805
#6 0x005d78b0 in HttpSM::handle_server_setup_error
(this=0x2b0e67ab0b20, event=104, data=0x2b0cf4dccdc8) at HttpSM.cc:5166
#7 0x005ccc11 in HttpSM::state_send_server_request_header
(this=0x2b0e67ab0b20, event=104, data=0x2b0cf4dccdc8) at HttpSM.cc:1963
#8 0x005cea7c in HttpSM::main_handler (this=0x2b0e67ab0b20, event=104,
data=0x2b0cf4dccdc8) at HttpSM.cc:2499
#9 0x004f460e in Continuation::handleEvent (this=0x2b0e67ab0b20,
event=104, data=0x2b0cf4dccdc8) at ../iocore/eventsystem/I_Continuation.h:146
#10 0x00731017 in read_signal_and_update (event=104, vc=0x2b0cf4d0)
at UnixNetVConnection.cc:138
#11 0x00731172 in read_signal_done (event=104, nh=0x2b0bad02ebc0,
vc=0x2b0cf4d0) at UnixNetVConnection.cc:168
#12 0x00733750 in UnixNetVConnection::readSignalDone
(this=0x2b0cf4d0, event=104, nh=0x2b0bad02ebc0) at UnixNetVConnection.cc:907
#13 0x0071f6ab in SSLNetVConnection::net_read_io (this=0x2b0cf4d0,
nh=0x2b0bad02ebc0, lthread=0x2b0bad02b010) at SSLNetVConnection.cc:334
#14 0x0072b09e in NetHandler::mainNetEvent (this=0x2b0bad02ebc0,
event=5, e=0x28be070) at UnixNet.cc:399
#15 0x004f460e in Continuation::handleEvent (this=0x2b0bad02ebc0,
event=5, data=0x28be070) at ../iocore/eventsystem/I_Continuation.h:146
#16 0x00751dca in EThread::process_event (this=0x2b0bad02b010,
e=0x28be070, calling_code=5) at UnixEThread.cc:145
#17 0x007522d4 in EThread::execute (this=0x2b0bad02b010) at
UnixEThread.cc:269
#18 0x00751328 in spawn_thread_internal (a=0x2bbc950) at Thread.cc:88
#19 0x003338607851 in start_thread () from /lib64/libpthread.so.0
#20 0x0033382e767d in clone () from /lib64/libc.so.6
(gdb) f 8
#8 0x005cea7c in HttpSM::main_handler (this=0x2b0e67ab0b20, event=104,
data=0x2b0cf4dccdc8) at HttpSM.cc:2499
2499HttpSM.cc: No such file or directory.
in HttpSM.cc
(gdb) p ((ProxyMutex *)HttpClientSession
*)(this-ua_entry-vc))-client_vc)-mutex))
$47 = (ProxyMutex *) 0x2b0cf509fe10
(gdb)
$48 = (ProxyMutex *) 0x2b0cf509fe10
(gdb)
$49 = (ProxyMutex *) 0x2b0cf509fe10
(gdb) bt
#0 0x00751cac in EThread::is_event_type (this=0x0, et=1) at
UnixEThread.cc:122
#1 0x0072f908 in UnixNetProcessor::connect_re_internal
(this=0x1018780, cont=0x2b0e67ab0b20, target=0x2b0e67ab11c8,
opt=0x2b0bae942650, servername=0x2b0ef61b2f10 mkfrm.zenfs.com)
at UnixNetProcessor.cc:249
#2 0x0051d367 in NetProcessor::connect_re (this=0x1018780,
cont=0x2b0e67ab0b20, addr=0x2b0e67ab11c8, opts=0x2b0bae942650,
servername=0x2b0ef61b2f10 mkfrm.zenfs.com)
at ../iocore/net/P_UnixNetProcessor.h:87
#3 0x005d6248 in HttpSM::do_http_server_open (this=0x2b0e67ab0b20,
raw=false) at HttpSM.cc:4653
#4 0x005dd871 in HttpSM::set_next_state (this=0x2b0e67ab0b20) at
HttpSM.cc:6988
#5 0x005dcc9c in HttpSM::call_transact_and_set_next_state
(this=0x2b0e67ab0b20, f=0x5f5604
HttpTransact::HandleResponse(HttpTransact::State*)) at HttpSM.cc:6805
#6 0x005d78b0 in HttpSM::handle_server_setup_error
(this=0x2b0e67ab0b20, event=104, data=0x2b0cf4dccdc8) at HttpSM.cc:5166
#7 0x005ccc11 in HttpSM::state_send_server_request_header
(this=0x2b0e67ab0b20, event=104, data=0x2b0cf4dccdc8) at HttpSM.cc:1963
#8 0x005cea7c in HttpSM::main_handler (this=0x2b0e67ab0b20, event=104,
data=0x2b0cf4dccdc8) at HttpSM.cc:2499
#9 0x004f460e in Continuation::handleEvent (this=0x2b0e67ab0b20,
event=104, data=0x2b0cf4dccdc8) at ../iocore/eventsystem/I_Continuation.h:146
#10 0x00731017 in read_signal_and_update (event=104, vc=0x2b0cf4d0)
at UnixNetVConnection.cc:138
#11 0x00731172 in read_signal_done (event=104, nh=0x2b0bad02ebc0,
[jira] [Comment Edited] (TS-3025) Segmentation fault
[
https://issues.apache.org/jira/browse/TS-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103744#comment-14103744
]
Wei Sun edited comment on TS-3025 at 8/20/14 10:45 AM:
---
Similar stack trace with 5.0.x after enabling spdy.
{code}
(gdb) bt
#0 0x00751cac in EThread::is_event_type (this=0x0, et=1) at
UnixEThread.cc:122
#1 0x0072f908 in UnixNetProcessor::connect_re_internal
(this=0x1018780, cont=0x2b0e67ab0b20, target=0x2b0e67ab11c8,
opt=0x2b0bae942650, servername=0x2b0ef61b2f10 mkfrm.zenfs.com)
at UnixNetProcessor.cc:249
#2 0x0051d367 in NetProcessor::connect_re (this=0x1018780,
cont=0x2b0e67ab0b20, addr=0x2b0e67ab11c8, opts=0x2b0bae942650,
servername=0x2b0ef61b2f10 mkfrm.zenfs.com)
at ../iocore/net/P_UnixNetProcessor.h:87
#3 0x005d6248 in HttpSM::do_http_server_open (this=0x2b0e67ab0b20,
raw=false) at HttpSM.cc:4653
#4 0x005dd871 in HttpSM::set_next_state (this=0x2b0e67ab0b20) at
HttpSM.cc:6988
#5 0x005dcc9c in HttpSM::call_transact_and_set_next_state
(this=0x2b0e67ab0b20, f=0x5f5604
HttpTransact::HandleResponse(HttpTransact::State*)) at HttpSM.cc:6805
#6 0x005d78b0 in HttpSM::handle_server_setup_error
(this=0x2b0e67ab0b20, event=104, data=0x2b0cf4dccdc8) at HttpSM.cc:5166
#7 0x005ccc11 in HttpSM::state_send_server_request_header
(this=0x2b0e67ab0b20, event=104, data=0x2b0cf4dccdc8) at HttpSM.cc:1963
#8 0x005cea7c in HttpSM::main_handler (this=0x2b0e67ab0b20, event=104,
data=0x2b0cf4dccdc8) at HttpSM.cc:2499
#9 0x004f460e in Continuation::handleEvent (this=0x2b0e67ab0b20,
event=104, data=0x2b0cf4dccdc8) at ../iocore/eventsystem/I_Continuation.h:146
#10 0x00731017 in read_signal_and_update (event=104, vc=0x2b0cf4d0)
at UnixNetVConnection.cc:138
#11 0x00731172 in read_signal_done (event=104, nh=0x2b0bad02ebc0,
vc=0x2b0cf4d0) at UnixNetVConnection.cc:168
#12 0x00733750 in UnixNetVConnection::readSignalDone
(this=0x2b0cf4d0, event=104, nh=0x2b0bad02ebc0) at UnixNetVConnection.cc:907
#13 0x0071f6ab in SSLNetVConnection::net_read_io (this=0x2b0cf4d0,
nh=0x2b0bad02ebc0, lthread=0x2b0bad02b010) at SSLNetVConnection.cc:334
#14 0x0072b09e in NetHandler::mainNetEvent (this=0x2b0bad02ebc0,
event=5, e=0x28be070) at UnixNet.cc:399
#15 0x004f460e in Continuation::handleEvent (this=0x2b0bad02ebc0,
event=5, data=0x28be070) at ../iocore/eventsystem/I_Continuation.h:146
#16 0x00751dca in EThread::process_event (this=0x2b0bad02b010,
e=0x28be070, calling_code=5) at UnixEThread.cc:145
#17 0x007522d4 in EThread::execute (this=0x2b0bad02b010) at
UnixEThread.cc:269
#18 0x00751328 in spawn_thread_internal (a=0x2bbc950) at Thread.cc:88
#19 0x003338607851 in start_thread () from /lib64/libpthread.so.0
#20 0x0033382e767d in clone () from /lib64/libc.so.6
(gdb) f 1
#1 0x0072f908 in UnixNetProcessor::connect_re_internal
(this=0x1018780, cont=0x2b0e67ab0b20, target=0x2b0e67ab11c8,
opt=0x2b0bae942650, servername=0x2b0ef61b2f10 mkfrm.zenfs.com)
at UnixNetProcessor.cc:249
249 UnixNetProcessor.cc: No such file or directory.
in UnixNetProcessor.cc
(gdb) p mutex
$50 = (ProxyMutex *) 0x2b0cf509fe10
(gdb) p mutex-thread_holding
$51 = (volatile EThreadPtr) 0x0
(gdb) f 8
#8 0x005cea7c in HttpSM::main_handler (this=0x2b0e67ab0b20, event=104,
data=0x2b0cf4dccdc8) at HttpSM.cc:2499
2499HttpSM.cc: No such file or directory.
in HttpSM.cc
(gdb) p ((ProxyMutex *)HttpClientSession
*)(this-ua_entry-vc))-client_vc)-mutex))
$52 = (ProxyMutex *) 0x2b0cf509fe10
(gdb) p ((ProxyMutex *)HttpClientSession
*)(this-ua_entry-vc))-client_vc)-mutex))-thread_holding
$53 = (volatile EThreadPtr) 0x0
(gdb) p ((ProxyMutex *)HttpClientSession
*)(this-ua_entry-vc))-client_vc)-mutex))-nthread_holding
$54 = 0
{code}
was (Author: sunwei):
Similar stack trace with 5.0.x after enabling spdy.
{code}
(gdb) bt
#0 0x00751cac in EThread::is_event_type (this=0x0, et=1) at
UnixEThread.cc:122
#1 0x0072f908 in UnixNetProcessor::connect_re_internal
(this=0x1018780, cont=0x2b0e67ab0b20, target=0x2b0e67ab11c8,
opt=0x2b0bae942650, servername=0x2b0ef61b2f10 mkfrm.zenfs.com)
at UnixNetProcessor.cc:249
#2 0x0051d367 in NetProcessor::connect_re (this=0x1018780,
cont=0x2b0e67ab0b20, addr=0x2b0e67ab11c8, opts=0x2b0bae942650,
servername=0x2b0ef61b2f10 mkfrm.zenfs.com)
at ../iocore/net/P_UnixNetProcessor.h:87
#3 0x005d6248 in HttpSM::do_http_server_open (this=0x2b0e67ab0b20,
raw=false) at HttpSM.cc:4653
#4 0x005dd871 in HttpSM::set_next_state (this=0x2b0e67ab0b20) at
HttpSM.cc:6988
#5 0x005dcc9c in HttpSM::call_transact_and_set_next_state
(this=0x2b0e67ab0b20, f=0x5f5604
HttpTransact::HandleResponse(HttpTransact::State*)) at HttpSM.cc:6805
#6
[jira] [Commented] (TS-3025) Segmentation fault
[
https://issues.apache.org/jira/browse/TS-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103776#comment-14103776
]
David Carlin commented on TS-3025:
--
Is this the same as TS-1798 ?
Segmentation fault
--
Key: TS-3025
URL: https://issues.apache.org/jira/browse/TS-3025
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.1.0
Reporter: bettydramit
Labels: crash
Env: Centos 6 x86_64 gitmaster version
enable spdy
{code}
`/usr/bin/traffic_server -M --httpport 80:fd=9,443:fd=10:ssl:proto=http;spdy'
{code}
core info
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf710)[0x2b920328b710]
/usr/bin/traffic_server(EThread::is_event_type(int)+0x9)[0x73f019]
/usr/bin/traffic_server(UnixNetProcessor::connect_re_internal(Continuation*,
sockaddr const*, NetVCOptions*)+0x382)[0x7182f2]
/usr/bin/traffic_server(HttpSM::do_http_server_open(bool)+0x71c)[0x5a96cc]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x4e0)[0x5ae690]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x84)[0x5ace74]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5ab6c8]
/usr/bin/traffic_server[0x71bb61]
/usr/bin/traffic_server[0x71f17f]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x7130e2]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x73f8af]
/usr/bin/traffic_server(EThread::execute()+0x43b)[0x7400db]
/usr/bin/traffic_server[0x73ec4a]
/lib64/libpthread.so.0(+0x79d1)[0x2b92032839d1]
/lib64/libc.so.6(clone+0x6d)[0x2b9204279b6d]
{code}
gdb info
{code}
Program terminated with signal 11, Segmentation fault.
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
(gdb) bt
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
#1 0x007182f2 in UnixNetProcessor::connect_re_internal (this=value
optimized out, cont=0x2aab21bed4e0,
target=value optimized out, opt=0x2b920706d940) at
UnixNetProcessor.cc:247
#2 0x005a96cc in connect_re (this=0x2aab21bed4e0, raw=value
optimized out) at ../../iocore/net/P_UnixNetProcessor.h:85
#3 HttpSM::do_http_server_open (this=0x2aab21bed4e0, raw=value optimized
out) at HttpSM.cc:4699
#4 0x005ae690 in HttpSM::set_next_state (this=0x2aab21bed4e0) at
HttpSM.cc:7024
#5 0x005ace74 in HttpSM::state_send_server_request_header
(this=0x2aab21bed4e0, event=104, data=0x2aab20a63420) at HttpSM.cc:1962
#6 0x005ab6c8 in HttpSM::main_handler (this=0x2aab21bed4e0,
event=104, data=0x2aab20a63420) at HttpSM.cc:2542
#7 0x0071bb61 in handleEvent (event=value optimized out,
nh=0x2b920646cbc0, vc=0x2aab20a63310)
at ../../iocore/eventsystem/I_Continuation.h:146
#8 read_signal_and_update (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:137
#9 read_signal_done (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:167
#10 0x0071f17f in read_from_net (nh=0x2b920646cbc0,
vc=0x2aab20a63310, thread=value optimized out) at UnixNetVConnection.cc:291
#11 0x007130e2 in NetHandler::mainNetEvent (this=0x2b920646cbc0,
event=value optimized out, e=value optimized out)
at UnixNet.cc:399
#12 0x0073f8af in handleEvent (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at I_Continuation.h:146
#13 EThread::process_event (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at UnixEThread.cc:144
#14 0x007400db in EThread::execute (this=0x2b9206469010) at
UnixEThread.cc:268
#15 0x0073ec4a in spawn_thread_internal (a=0x2ac4c10) at Thread.cc:88
#16 0x2b92032839d1 in start_thread () from /lib64/libpthread.so.0
#17 0x2b9204279b6d in clone () from /lib64/libc.so.6
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-3025) Segmentation fault when SPDY enabled
[
https://issues.apache.org/jira/browse/TS-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Carlin updated TS-3025:
-
Summary: Segmentation fault when SPDY enabled (was: Segmentation fault)
Segmentation fault when SPDY enabled
Key: TS-3025
URL: https://issues.apache.org/jira/browse/TS-3025
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.1.0
Reporter: bettydramit
Labels: crash
Env: Centos 6 x86_64 gitmaster version
enable spdy
{code}
`/usr/bin/traffic_server -M --httpport 80:fd=9,443:fd=10:ssl:proto=http;spdy'
{code}
core info
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf710)[0x2b920328b710]
/usr/bin/traffic_server(EThread::is_event_type(int)+0x9)[0x73f019]
/usr/bin/traffic_server(UnixNetProcessor::connect_re_internal(Continuation*,
sockaddr const*, NetVCOptions*)+0x382)[0x7182f2]
/usr/bin/traffic_server(HttpSM::do_http_server_open(bool)+0x71c)[0x5a96cc]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x4e0)[0x5ae690]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x84)[0x5ace74]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5ab6c8]
/usr/bin/traffic_server[0x71bb61]
/usr/bin/traffic_server[0x71f17f]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x7130e2]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x73f8af]
/usr/bin/traffic_server(EThread::execute()+0x43b)[0x7400db]
/usr/bin/traffic_server[0x73ec4a]
/lib64/libpthread.so.0(+0x79d1)[0x2b92032839d1]
/lib64/libc.so.6(clone+0x6d)[0x2b9204279b6d]
{code}
gdb info
{code}
Program terminated with signal 11, Segmentation fault.
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
(gdb) bt
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
#1 0x007182f2 in UnixNetProcessor::connect_re_internal (this=value
optimized out, cont=0x2aab21bed4e0,
target=value optimized out, opt=0x2b920706d940) at
UnixNetProcessor.cc:247
#2 0x005a96cc in connect_re (this=0x2aab21bed4e0, raw=value
optimized out) at ../../iocore/net/P_UnixNetProcessor.h:85
#3 HttpSM::do_http_server_open (this=0x2aab21bed4e0, raw=value optimized
out) at HttpSM.cc:4699
#4 0x005ae690 in HttpSM::set_next_state (this=0x2aab21bed4e0) at
HttpSM.cc:7024
#5 0x005ace74 in HttpSM::state_send_server_request_header
(this=0x2aab21bed4e0, event=104, data=0x2aab20a63420) at HttpSM.cc:1962
#6 0x005ab6c8 in HttpSM::main_handler (this=0x2aab21bed4e0,
event=104, data=0x2aab20a63420) at HttpSM.cc:2542
#7 0x0071bb61 in handleEvent (event=value optimized out,
nh=0x2b920646cbc0, vc=0x2aab20a63310)
at ../../iocore/eventsystem/I_Continuation.h:146
#8 read_signal_and_update (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:137
#9 read_signal_done (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:167
#10 0x0071f17f in read_from_net (nh=0x2b920646cbc0,
vc=0x2aab20a63310, thread=value optimized out) at UnixNetVConnection.cc:291
#11 0x007130e2 in NetHandler::mainNetEvent (this=0x2b920646cbc0,
event=value optimized out, e=value optimized out)
at UnixNet.cc:399
#12 0x0073f8af in handleEvent (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at I_Continuation.h:146
#13 EThread::process_event (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at UnixEThread.cc:144
#14 0x007400db in EThread::execute (this=0x2b9206469010) at
UnixEThread.cc:268
#15 0x0073ec4a in spawn_thread_internal (a=0x2ac4c10) at Thread.cc:88
#16 0x2b92032839d1 in start_thread () from /lib64/libpthread.so.0
#17 0x2b9204279b6d in clone () from /lib64/libc.so.6
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2912) HEAD transaction on stale entry deletes cache entry
[ https://issues.apache.org/jira/browse/TS-2912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103812#comment-14103812 ] ASF subversion and git services commented on TS-2912: - Commit d632e7f5d50eb27cfaf4bee384fb8f999c890a5e in trafficserver's branch refs/heads/master from [~taorui] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d632e7f ] TS-2912: Don't clear stale object on HEAD request. HEAD transaction on stale entry deletes cache entry --- Key: TS-2912 URL: https://issues.apache.org/jira/browse/TS-2912 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: William Bardwell Assignee: weijin Labels: review Fix For: 5.1.0 Attachments: ts-2912.try1.diff On a stale cache entry a HEAD gets tunneled to the origin, but when a 200 comes back HttpTransact::handle_cache_operation_on_forward_server_response(State* s) deletes the cache entry, it seems like it should just ignore it (or check ETag/Last-Modified and maybe delete if those don't match, but not unconditionally.) I am seeing this with 4.2.X with a plugin fiddling with stuff, but the code looks the same in trunk, line 4318 looks like the problem line. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (TS-2995) Setting client response TOS/DSCP field has no effect
[
https://issues.apache.org/jira/browse/TS-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll resolved TS-2995.
-
Resolution: Fixed
Setting client response TOS/DSCP field has no effect
Key: TS-2995
URL: https://issues.apache.org/jira/browse/TS-2995
Project: Traffic Server
Issue Type: Bug
Reporter: Jack Bates
Assignee: Jack Bates
Fix For: 5.1.0
{{proxy.config.net.sock_packet_tos_in}} has no effect if
{{proxy.config.accept_threads}} is not zero.
If it is zero then {{UnixNetProcessor::accept_internal()}} calls
{{NetAccept::init_accept_per_thread()}} which eventually calls
{{NetAccept::acceptFastEvent()}} in which there's code to set the {{SO_MARK}}
and {{IP_TOS}} socket options.
But if it's not zero then {{UnixNetProcessor::accept_internal()}} instead
calls {{NetAccept::init_accept_loop()}} which eventually calls
{{NetAccept::do_blocking_accept()}}
One fix is to copy the code to set the {{SO_MARK}} and {{IP_TOS}} socket
options from {{NetAccept::acceptFastEvent()}} to
{{NetAccept::do_blocking_accept()}}
{code}
--- a/iocore/net/UnixNetAccept.cc
+++ b/iocore/net/UnixNetAccept.cc
@@ -275,6 +275,18 @@ NetAccept::do_blocking_accept(EThread * t)
return -1;
}
+#if TS_HAS_SO_MARK
+ if (packet_mark != 0) {
+safe_setsockopt(con.fd, SOL_SOCKET, SO_MARK, reinterpret_castchar
*(
+ }
+#endif
+
+#if TS_HAS_IP_TOS
+ if (packet_tos != 0) {
+safe_setsockopt(con.fd, IPPROTO_IP, IP_TOS, reinterpret_castchar
*(p
+ }
+#endif
+
// Use 'NULL' to Bypass thread allocator
vc = (UnixNetVConnection *)this-getNetProcessor()-allocate_vc(NULL);
if (!vc) {
{code}
I tested this change and verified that
{{proxy.config.net.sock_packet_tos_in}} does correctly set the TOS/DSCP field.
This issue was reported by Jason Strongman on the users list
http://thread.gmane.org/gmane.comp.apache.trafficserver.user/4141/focus=4202
{{proxy.config.net.sock_packet_tos_in}} was introduced in TS-1090 and commit
b77838991531d6cb402618c3d690b83e95b92d63
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2995) Setting client response TOS/DSCP field has no effect
[
https://issues.apache.org/jira/browse/TS-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103817#comment-14103817
]
ASF subversion and git services commented on TS-2995:
-
Commit cde870b312e5f08a787ba8512bfcc7b34853c569 in trafficserver's branch
refs/heads/master from [~nottheoilrig]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=cde870b ]
TS-2995: Apply TOS/SO marks to client connection in all accept cases.
Setting client response TOS/DSCP field has no effect
Key: TS-2995
URL: https://issues.apache.org/jira/browse/TS-2995
Project: Traffic Server
Issue Type: Bug
Reporter: Jack Bates
Assignee: Jack Bates
Fix For: 5.1.0
{{proxy.config.net.sock_packet_tos_in}} has no effect if
{{proxy.config.accept_threads}} is not zero.
If it is zero then {{UnixNetProcessor::accept_internal()}} calls
{{NetAccept::init_accept_per_thread()}} which eventually calls
{{NetAccept::acceptFastEvent()}} in which there's code to set the {{SO_MARK}}
and {{IP_TOS}} socket options.
But if it's not zero then {{UnixNetProcessor::accept_internal()}} instead
calls {{NetAccept::init_accept_loop()}} which eventually calls
{{NetAccept::do_blocking_accept()}}
One fix is to copy the code to set the {{SO_MARK}} and {{IP_TOS}} socket
options from {{NetAccept::acceptFastEvent()}} to
{{NetAccept::do_blocking_accept()}}
{code}
--- a/iocore/net/UnixNetAccept.cc
+++ b/iocore/net/UnixNetAccept.cc
@@ -275,6 +275,18 @@ NetAccept::do_blocking_accept(EThread * t)
return -1;
}
+#if TS_HAS_SO_MARK
+ if (packet_mark != 0) {
+safe_setsockopt(con.fd, SOL_SOCKET, SO_MARK, reinterpret_castchar
*(
+ }
+#endif
+
+#if TS_HAS_IP_TOS
+ if (packet_tos != 0) {
+safe_setsockopt(con.fd, IPPROTO_IP, IP_TOS, reinterpret_castchar
*(p
+ }
+#endif
+
// Use 'NULL' to Bypass thread allocator
vc = (UnixNetVConnection *)this-getNetProcessor()-allocate_vc(NULL);
if (!vc) {
{code}
I tested this change and verified that
{{proxy.config.net.sock_packet_tos_in}} does correctly set the TOS/DSCP field.
This issue was reported by Jason Strongman on the users list
http://thread.gmane.org/gmane.comp.apache.trafficserver.user/4141/focus=4202
{{proxy.config.net.sock_packet_tos_in}} was introduced in TS-1090 and commit
b77838991531d6cb402618c3d690b83e95b92d63
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-3026) SPDY not forwarding Accept-Encoding headers for Firefox
[ https://issues.apache.org/jira/browse/TS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3026: -- Fix Version/s: sometime SPDY not forwarding Accept-Encoding headers for Firefox --- Key: TS-3026 URL: https://issues.apache.org/jira/browse/TS-3026 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Scott Beardsley Fix For: sometime Attachments: Screen Shot 2014-08-20 at 1.06.42 AM.png Firefox is claiming to be sending the Accept-Encoding header (specifically Accept-Encoding: gzip, deflate) but somewhere it appears to be dropped. I don't see it show up in the logs with http.* debug on. Here is what TS sees: + Incoming Request + -- State Machine Id: 0 GET http://origin.example.com/ HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-language: en-US,en;q=0.5 cookie: cookies dnt: 1 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0 Host: example.com -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3025) Segmentation fault when SPDY enabled
[
https://issues.apache.org/jira/browse/TS-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-3025:
--
Fix Version/s: 5.2.0
Segmentation fault when SPDY enabled
Key: TS-3025
URL: https://issues.apache.org/jira/browse/TS-3025
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.1.0
Reporter: bettydramit
Labels: crash
Fix For: 5.2.0
Env: Centos 6 x86_64 gitmaster version
enable spdy
{code}
`/usr/bin/traffic_server -M --httpport 80:fd=9,443:fd=10:ssl:proto=http;spdy'
{code}
core info
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf710)[0x2b920328b710]
/usr/bin/traffic_server(EThread::is_event_type(int)+0x9)[0x73f019]
/usr/bin/traffic_server(UnixNetProcessor::connect_re_internal(Continuation*,
sockaddr const*, NetVCOptions*)+0x382)[0x7182f2]
/usr/bin/traffic_server(HttpSM::do_http_server_open(bool)+0x71c)[0x5a96cc]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x4e0)[0x5ae690]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x84)[0x5ace74]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5ab6c8]
/usr/bin/traffic_server[0x71bb61]
/usr/bin/traffic_server[0x71f17f]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x7130e2]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x73f8af]
/usr/bin/traffic_server(EThread::execute()+0x43b)[0x7400db]
/usr/bin/traffic_server[0x73ec4a]
/lib64/libpthread.so.0(+0x79d1)[0x2b92032839d1]
/lib64/libc.so.6(clone+0x6d)[0x2b9204279b6d]
{code}
gdb info
{code}
Program terminated with signal 11, Segmentation fault.
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
(gdb) bt
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
#1 0x007182f2 in UnixNetProcessor::connect_re_internal (this=value
optimized out, cont=0x2aab21bed4e0,
target=value optimized out, opt=0x2b920706d940) at
UnixNetProcessor.cc:247
#2 0x005a96cc in connect_re (this=0x2aab21bed4e0, raw=value
optimized out) at ../../iocore/net/P_UnixNetProcessor.h:85
#3 HttpSM::do_http_server_open (this=0x2aab21bed4e0, raw=value optimized
out) at HttpSM.cc:4699
#4 0x005ae690 in HttpSM::set_next_state (this=0x2aab21bed4e0) at
HttpSM.cc:7024
#5 0x005ace74 in HttpSM::state_send_server_request_header
(this=0x2aab21bed4e0, event=104, data=0x2aab20a63420) at HttpSM.cc:1962
#6 0x005ab6c8 in HttpSM::main_handler (this=0x2aab21bed4e0,
event=104, data=0x2aab20a63420) at HttpSM.cc:2542
#7 0x0071bb61 in handleEvent (event=value optimized out,
nh=0x2b920646cbc0, vc=0x2aab20a63310)
at ../../iocore/eventsystem/I_Continuation.h:146
#8 read_signal_and_update (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:137
#9 read_signal_done (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:167
#10 0x0071f17f in read_from_net (nh=0x2b920646cbc0,
vc=0x2aab20a63310, thread=value optimized out) at UnixNetVConnection.cc:291
#11 0x007130e2 in NetHandler::mainNetEvent (this=0x2b920646cbc0,
event=value optimized out, e=value optimized out)
at UnixNet.cc:399
#12 0x0073f8af in handleEvent (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at I_Continuation.h:146
#13 EThread::process_event (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at UnixEThread.cc:144
#14 0x007400db in EThread::execute (this=0x2b9206469010) at
UnixEThread.cc:268
#15 0x0073ec4a in spawn_thread_internal (a=0x2ac4c10) at Thread.cc:88
#16 0x2b92032839d1 in start_thread () from /lib64/libpthread.so.0
#17 0x2b9204279b6d in clone () from /lib64/libc.so.6
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3025) Segmentation fault when SPDY enabled
[
https://issues.apache.org/jira/browse/TS-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103917#comment-14103917
]
Leif Hedstrom commented on TS-3025:
---
Linking this for now, but it seems possible this is a dupe.
Segmentation fault when SPDY enabled
Key: TS-3025
URL: https://issues.apache.org/jira/browse/TS-3025
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.1.0
Reporter: bettydramit
Labels: crash
Fix For: 5.2.0
Env: Centos 6 x86_64 gitmaster version
enable spdy
{code}
`/usr/bin/traffic_server -M --httpport 80:fd=9,443:fd=10:ssl:proto=http;spdy'
{code}
core info
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf710)[0x2b920328b710]
/usr/bin/traffic_server(EThread::is_event_type(int)+0x9)[0x73f019]
/usr/bin/traffic_server(UnixNetProcessor::connect_re_internal(Continuation*,
sockaddr const*, NetVCOptions*)+0x382)[0x7182f2]
/usr/bin/traffic_server(HttpSM::do_http_server_open(bool)+0x71c)[0x5a96cc]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x4e0)[0x5ae690]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x84)[0x5ace74]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5ab6c8]
/usr/bin/traffic_server[0x71bb61]
/usr/bin/traffic_server[0x71f17f]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x7130e2]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x73f8af]
/usr/bin/traffic_server(EThread::execute()+0x43b)[0x7400db]
/usr/bin/traffic_server[0x73ec4a]
/lib64/libpthread.so.0(+0x79d1)[0x2b92032839d1]
/lib64/libc.so.6(clone+0x6d)[0x2b9204279b6d]
{code}
gdb info
{code}
Program terminated with signal 11, Segmentation fault.
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
(gdb) bt
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
#1 0x007182f2 in UnixNetProcessor::connect_re_internal (this=value
optimized out, cont=0x2aab21bed4e0,
target=value optimized out, opt=0x2b920706d940) at
UnixNetProcessor.cc:247
#2 0x005a96cc in connect_re (this=0x2aab21bed4e0, raw=value
optimized out) at ../../iocore/net/P_UnixNetProcessor.h:85
#3 HttpSM::do_http_server_open (this=0x2aab21bed4e0, raw=value optimized
out) at HttpSM.cc:4699
#4 0x005ae690 in HttpSM::set_next_state (this=0x2aab21bed4e0) at
HttpSM.cc:7024
#5 0x005ace74 in HttpSM::state_send_server_request_header
(this=0x2aab21bed4e0, event=104, data=0x2aab20a63420) at HttpSM.cc:1962
#6 0x005ab6c8 in HttpSM::main_handler (this=0x2aab21bed4e0,
event=104, data=0x2aab20a63420) at HttpSM.cc:2542
#7 0x0071bb61 in handleEvent (event=value optimized out,
nh=0x2b920646cbc0, vc=0x2aab20a63310)
at ../../iocore/eventsystem/I_Continuation.h:146
#8 read_signal_and_update (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:137
#9 read_signal_done (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:167
#10 0x0071f17f in read_from_net (nh=0x2b920646cbc0,
vc=0x2aab20a63310, thread=value optimized out) at UnixNetVConnection.cc:291
#11 0x007130e2 in NetHandler::mainNetEvent (this=0x2b920646cbc0,
event=value optimized out, e=value optimized out)
at UnixNet.cc:399
#12 0x0073f8af in handleEvent (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at I_Continuation.h:146
#13 EThread::process_event (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at UnixEThread.cc:144
#14 0x007400db in EThread::execute (this=0x2b9206469010) at
UnixEThread.cc:268
#15 0x0073ec4a in spawn_thread_internal (a=0x2ac4c10) at Thread.cc:88
#16 0x2b92032839d1 in start_thread () from /lib64/libpthread.so.0
#17 0x2b9204279b6d in clone () from /lib64/libc.so.6
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3025) Segmentation fault when SPDY enabled
[
https://issues.apache.org/jira/browse/TS-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103916#comment-14103916
]
Leif Hedstrom commented on TS-3025:
---
Yeah, this looks very similar to TS-1798, good catch.
Segmentation fault when SPDY enabled
Key: TS-3025
URL: https://issues.apache.org/jira/browse/TS-3025
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.1.0
Reporter: bettydramit
Labels: crash
Fix For: 5.2.0
Env: Centos 6 x86_64 gitmaster version
enable spdy
{code}
`/usr/bin/traffic_server -M --httpport 80:fd=9,443:fd=10:ssl:proto=http;spdy'
{code}
core info
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf710)[0x2b920328b710]
/usr/bin/traffic_server(EThread::is_event_type(int)+0x9)[0x73f019]
/usr/bin/traffic_server(UnixNetProcessor::connect_re_internal(Continuation*,
sockaddr const*, NetVCOptions*)+0x382)[0x7182f2]
/usr/bin/traffic_server(HttpSM::do_http_server_open(bool)+0x71c)[0x5a96cc]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x4e0)[0x5ae690]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x84)[0x5ace74]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5ab6c8]
/usr/bin/traffic_server[0x71bb61]
/usr/bin/traffic_server[0x71f17f]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x7130e2]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x73f8af]
/usr/bin/traffic_server(EThread::execute()+0x43b)[0x7400db]
/usr/bin/traffic_server[0x73ec4a]
/lib64/libpthread.so.0(+0x79d1)[0x2b92032839d1]
/lib64/libc.so.6(clone+0x6d)[0x2b9204279b6d]
{code}
gdb info
{code}
Program terminated with signal 11, Segmentation fault.
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
(gdb) bt
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
#1 0x007182f2 in UnixNetProcessor::connect_re_internal (this=value
optimized out, cont=0x2aab21bed4e0,
target=value optimized out, opt=0x2b920706d940) at
UnixNetProcessor.cc:247
#2 0x005a96cc in connect_re (this=0x2aab21bed4e0, raw=value
optimized out) at ../../iocore/net/P_UnixNetProcessor.h:85
#3 HttpSM::do_http_server_open (this=0x2aab21bed4e0, raw=value optimized
out) at HttpSM.cc:4699
#4 0x005ae690 in HttpSM::set_next_state (this=0x2aab21bed4e0) at
HttpSM.cc:7024
#5 0x005ace74 in HttpSM::state_send_server_request_header
(this=0x2aab21bed4e0, event=104, data=0x2aab20a63420) at HttpSM.cc:1962
#6 0x005ab6c8 in HttpSM::main_handler (this=0x2aab21bed4e0,
event=104, data=0x2aab20a63420) at HttpSM.cc:2542
#7 0x0071bb61 in handleEvent (event=value optimized out,
nh=0x2b920646cbc0, vc=0x2aab20a63310)
at ../../iocore/eventsystem/I_Continuation.h:146
#8 read_signal_and_update (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:137
#9 read_signal_done (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:167
#10 0x0071f17f in read_from_net (nh=0x2b920646cbc0,
vc=0x2aab20a63310, thread=value optimized out) at UnixNetVConnection.cc:291
#11 0x007130e2 in NetHandler::mainNetEvent (this=0x2b920646cbc0,
event=value optimized out, e=value optimized out)
at UnixNet.cc:399
#12 0x0073f8af in handleEvent (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at I_Continuation.h:146
#13 EThread::process_event (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at UnixEThread.cc:144
#14 0x007400db in EThread::execute (this=0x2b9206469010) at
UnixEThread.cc:268
#15 0x0073ec4a in spawn_thread_internal (a=0x2ac4c10) at Thread.cc:88
#16 0x2b92032839d1 in start_thread () from /lib64/libpthread.so.0
#17 0x2b9204279b6d in clone () from /lib64/libc.so.6
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-3005) Rename ats_speed plugin - ats_pagespeed
[ https://issues.apache.org/jira/browse/TS-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103920#comment-14103920 ] Leif Hedstrom edited comment on TS-3005 at 8/20/14 2:17 PM: Right, we really, really would prefer to get this in before v5.1.0 is branched and released. Which is like, now :). was (Author: zwoop): Right, we really, really would prefer to get this in before v5.1.0 is branched and released. Rename ats_speed plugin - ats_pagespeed Key: TS-3005 URL: https://issues.apache.org/jira/browse/TS-3005 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Otto van der Schaaf Assignee: Otto van der Schaaf Fix For: 5.1.0 Renaming the plugin to ats_pagespeed just was approved by Google. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3005) Rename ats_speed plugin - ats_pagespeed
[ https://issues.apache.org/jira/browse/TS-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103920#comment-14103920 ] Leif Hedstrom commented on TS-3005: --- Right, we really, really would prefer to get this in before v5.1.0 is branched and released. Rename ats_speed plugin - ats_pagespeed Key: TS-3005 URL: https://issues.apache.org/jira/browse/TS-3005 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Otto van der Schaaf Assignee: Otto van der Schaaf Fix For: 5.1.0 Renaming the plugin to ats_pagespeed just was approved by Google. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3025) Segmentation fault when SPDY enabled
[
https://issues.apache.org/jira/browse/TS-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103923#comment-14103923
]
bettydramit commented on TS-3025:
-
same as TS-1798.
close this issue?
Segmentation fault when SPDY enabled
Key: TS-3025
URL: https://issues.apache.org/jira/browse/TS-3025
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.1.0
Reporter: bettydramit
Labels: crash
Fix For: 5.2.0
Env: Centos 6 x86_64 gitmaster version
enable spdy
{code}
`/usr/bin/traffic_server -M --httpport 80:fd=9,443:fd=10:ssl:proto=http;spdy'
{code}
core info
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf710)[0x2b920328b710]
/usr/bin/traffic_server(EThread::is_event_type(int)+0x9)[0x73f019]
/usr/bin/traffic_server(UnixNetProcessor::connect_re_internal(Continuation*,
sockaddr const*, NetVCOptions*)+0x382)[0x7182f2]
/usr/bin/traffic_server(HttpSM::do_http_server_open(bool)+0x71c)[0x5a96cc]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x4e0)[0x5ae690]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x84)[0x5ace74]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5ab6c8]
/usr/bin/traffic_server[0x71bb61]
/usr/bin/traffic_server[0x71f17f]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x7130e2]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x73f8af]
/usr/bin/traffic_server(EThread::execute()+0x43b)[0x7400db]
/usr/bin/traffic_server[0x73ec4a]
/lib64/libpthread.so.0(+0x79d1)[0x2b92032839d1]
/lib64/libc.so.6(clone+0x6d)[0x2b9204279b6d]
{code}
gdb info
{code}
Program terminated with signal 11, Segmentation fault.
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
(gdb) bt
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
#1 0x007182f2 in UnixNetProcessor::connect_re_internal (this=value
optimized out, cont=0x2aab21bed4e0,
target=value optimized out, opt=0x2b920706d940) at
UnixNetProcessor.cc:247
#2 0x005a96cc in connect_re (this=0x2aab21bed4e0, raw=value
optimized out) at ../../iocore/net/P_UnixNetProcessor.h:85
#3 HttpSM::do_http_server_open (this=0x2aab21bed4e0, raw=value optimized
out) at HttpSM.cc:4699
#4 0x005ae690 in HttpSM::set_next_state (this=0x2aab21bed4e0) at
HttpSM.cc:7024
#5 0x005ace74 in HttpSM::state_send_server_request_header
(this=0x2aab21bed4e0, event=104, data=0x2aab20a63420) at HttpSM.cc:1962
#6 0x005ab6c8 in HttpSM::main_handler (this=0x2aab21bed4e0,
event=104, data=0x2aab20a63420) at HttpSM.cc:2542
#7 0x0071bb61 in handleEvent (event=value optimized out,
nh=0x2b920646cbc0, vc=0x2aab20a63310)
at ../../iocore/eventsystem/I_Continuation.h:146
#8 read_signal_and_update (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:137
#9 read_signal_done (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:167
#10 0x0071f17f in read_from_net (nh=0x2b920646cbc0,
vc=0x2aab20a63310, thread=value optimized out) at UnixNetVConnection.cc:291
#11 0x007130e2 in NetHandler::mainNetEvent (this=0x2b920646cbc0,
event=value optimized out, e=value optimized out)
at UnixNet.cc:399
#12 0x0073f8af in handleEvent (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at I_Continuation.h:146
#13 EThread::process_event (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at UnixEThread.cc:144
#14 0x007400db in EThread::execute (this=0x2b9206469010) at
UnixEThread.cc:268
#15 0x0073ec4a in spawn_thread_internal (a=0x2ac4c10) at Thread.cc:88
#16 0x2b92032839d1 in start_thread () from /lib64/libpthread.so.0
#17 0x2b9204279b6d in clone () from /lib64/libc.so.6
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3023) Support space separated values in inline plugin parameters in remap rules
[ https://issues.apache.org/jira/browse/TS-3023?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103954#comment-14103954 ] Sudheer Vinukonda commented on TS-3023: --- Updated patch with tests attached. Support space separated values in inline plugin parameters in remap rules - Key: TS-3023 URL: https://issues.apache.org/jira/browse/TS-3023 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Sudheer Vinukonda Fix For: 5.2.0 Attachments: TS-3023.diff While reviewing and testing TS-2947, Leif found that, space separated values are not supported correctly for inline plugin params whereas, they work as expected when specified in the config file. For example, @pparam=proxy.config.foo='bar beer' results only in setting proxy.config.foo=bar whereas CONFIG proxy.config.foo STRING 'bar beer' results in setting proxy.config.foo='bar beer' Further analysis revealed that the limitation is in parsing/tokenizing the input, which always treats space or tab as delimiters, regardless of whether they are included within quotes. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3025) Segmentation fault when SPDY enabled
[
https://issues.apache.org/jira/browse/TS-3025?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14103976#comment-14103976
]
Leif Hedstrom commented on TS-3025:
---
Yeah remove the fix version and close it as a dupe please
Segmentation fault when SPDY enabled
Key: TS-3025
URL: https://issues.apache.org/jira/browse/TS-3025
Project: Traffic Server
Issue Type: Bug
Affects Versions: 5.1.0
Reporter: bettydramit
Labels: crash
Fix For: 5.2.0
Env: Centos 6 x86_64 gitmaster version
enable spdy
{code}
`/usr/bin/traffic_server -M --httpport 80:fd=9,443:fd=10:ssl:proto=http;spdy'
{code}
core info
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf710)[0x2b920328b710]
/usr/bin/traffic_server(EThread::is_event_type(int)+0x9)[0x73f019]
/usr/bin/traffic_server(UnixNetProcessor::connect_re_internal(Continuation*,
sockaddr const*, NetVCOptions*)+0x382)[0x7182f2]
/usr/bin/traffic_server(HttpSM::do_http_server_open(bool)+0x71c)[0x5a96cc]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x4e0)[0x5ae690]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x84)[0x5ace74]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x5ab6c8]
/usr/bin/traffic_server[0x71bb61]
/usr/bin/traffic_server[0x71f17f]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x7130e2]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x8f)[0x73f8af]
/usr/bin/traffic_server(EThread::execute()+0x43b)[0x7400db]
/usr/bin/traffic_server[0x73ec4a]
/lib64/libpthread.so.0(+0x79d1)[0x2b92032839d1]
/lib64/libc.so.6(clone+0x6d)[0x2b9204279b6d]
{code}
gdb info
{code}
Program terminated with signal 11, Segmentation fault.
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
(gdb) bt
#0 0x0073f019 in EThread::is_event_type (this=0x0, et=0) at
UnixEThread.cc:120
#1 0x007182f2 in UnixNetProcessor::connect_re_internal (this=value
optimized out, cont=0x2aab21bed4e0,
target=value optimized out, opt=0x2b920706d940) at
UnixNetProcessor.cc:247
#2 0x005a96cc in connect_re (this=0x2aab21bed4e0, raw=value
optimized out) at ../../iocore/net/P_UnixNetProcessor.h:85
#3 HttpSM::do_http_server_open (this=0x2aab21bed4e0, raw=value optimized
out) at HttpSM.cc:4699
#4 0x005ae690 in HttpSM::set_next_state (this=0x2aab21bed4e0) at
HttpSM.cc:7024
#5 0x005ace74 in HttpSM::state_send_server_request_header
(this=0x2aab21bed4e0, event=104, data=0x2aab20a63420) at HttpSM.cc:1962
#6 0x005ab6c8 in HttpSM::main_handler (this=0x2aab21bed4e0,
event=104, data=0x2aab20a63420) at HttpSM.cc:2542
#7 0x0071bb61 in handleEvent (event=value optimized out,
nh=0x2b920646cbc0, vc=0x2aab20a63310)
at ../../iocore/eventsystem/I_Continuation.h:146
#8 read_signal_and_update (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:137
#9 read_signal_done (event=value optimized out, nh=0x2b920646cbc0,
vc=0x2aab20a63310) at UnixNetVConnection.cc:167
#10 0x0071f17f in read_from_net (nh=0x2b920646cbc0,
vc=0x2aab20a63310, thread=value optimized out) at UnixNetVConnection.cc:291
#11 0x007130e2 in NetHandler::mainNetEvent (this=0x2b920646cbc0,
event=value optimized out, e=value optimized out)
at UnixNet.cc:399
#12 0x0073f8af in handleEvent (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at I_Continuation.h:146
#13 EThread::process_event (this=0x2b9206469010, e=0x2b9207986cc0,
calling_code=5) at UnixEThread.cc:144
#14 0x007400db in EThread::execute (this=0x2b9206469010) at
UnixEThread.cc:268
#15 0x0073ec4a in spawn_thread_internal (a=0x2ac4c10) at Thread.cc:88
#16 0x2b92032839d1 in start_thread () from /lib64/libpthread.so.0
#17 0x2b9204279b6d in clone () from /lib64/libc.so.6
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-3026) SPDY not forwarding Accept-Encoding headers for Firefox
[ https://issues.apache.org/jira/browse/TS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14104058#comment-14104058 ] Sudheer Vinukonda commented on TS-3026: --- I am thinking of adding the header accept-encoding:gzip, deflate for all spdy connections (if it's not already received). Please comment if there are any concerns/suggestions. SPDY not forwarding Accept-Encoding headers for Firefox --- Key: TS-3026 URL: https://issues.apache.org/jira/browse/TS-3026 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Scott Beardsley Fix For: sometime Attachments: Screen Shot 2014-08-20 at 1.06.42 AM.png Firefox is claiming to be sending the Accept-Encoding header (specifically Accept-Encoding: gzip, deflate) but somewhere it appears to be dropped. I don't see it show up in the logs with http.* debug on. Here is what TS sees: + Incoming Request + -- State Machine Id: 0 GET http://origin.example.com/ HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-language: en-US,en;q=0.5 cookie: cookies dnt: 1 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0 Host: example.com -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3026) SPDY not forwarding Accept-Encoding headers for Firefox
[ https://issues.apache.org/jira/browse/TS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14104073#comment-14104073 ] Scott Beardsley commented on TS-3026: - Sudheer I think that makes sense. It might not be necessary for origins which are also speaking SPDY but that is a premature optimization. The chromium folks appear to have taken the trade off of just sending the header instead of relying on the specific requirements in the spec. Specifically: See http://dev.chromium.org/spdy/spdy-protocol/spdy-protocol-draft3#TOC-3.2.1-Request where it says: User-agents MUST support gzip compression. Regardless of the Accept-Encoding sent by the user-agent, the server may always send content encoded with gzip or deflate encoding. I think TS would need to solve this one of two ways: 1. make sure the accept-encoding header is always present when the origin doesn't speak spdy but spdy is being used between the proxy and user agent. 2. tell the origin that the proxy is speaking spdy (and update all origins to understand that signal and gzip accordingly) 3. makes sure to gzip all SPDY traffic which is compressible (and look at content-type responses to make sure jpegs aren't compressed) #1 sounds like the easiest ;) SPDY not forwarding Accept-Encoding headers for Firefox --- Key: TS-3026 URL: https://issues.apache.org/jira/browse/TS-3026 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Scott Beardsley Fix For: sometime Attachments: Screen Shot 2014-08-20 at 1.06.42 AM.png Firefox is claiming to be sending the Accept-Encoding header (specifically Accept-Encoding: gzip, deflate) but somewhere it appears to be dropped. I don't see it show up in the logs with http.* debug on. Here is what TS sees: + Incoming Request + -- State Machine Id: 0 GET http://origin.example.com/ HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-language: en-US,en;q=0.5 cookie: cookies dnt: 1 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0 Host: example.com -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-3027) Hashed SSL Intermediate Server Certs not recognized
Steven Feltner created TS-3027:
--
Summary: Hashed SSL Intermediate Server Certs not recognized
Key: TS-3027
URL: https://issues.apache.org/jira/browse/TS-3027
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Steven Feltner
Tested on:
CentOS 6.5 x86_64
trafficserver-5.0.1
Pertinent Config Values:
CONFIG proxy.config.ssl.CA.cert.filename STRING NULL
#CONFIG proxy.config.ssl.CA.cert.filename STRING combined_ca_bundle.crt
CONFIG proxy.config.ssl.CA.cert.path STRING /var/linhosting/users/local
(with and without CA.cert.filename configured)
CONFIG proxy.config.ssl.client.certification_level INT 0
CONFIG proxy.config.ssl.client.verify.server INT 0
c_rehash (from OpenSSL) called from command line to create hash symlinks
Currently, SSL_CTX_load_verify_locations is only called in two cases:
if (params-clientCertLevel != 0) {
and
if (params-clientVerify) {
Attached patch will create a precedence such that:
if ssl_ca_name= is configured in ssl_multicert.config
use that to build the cert chain
else if proxy.config.ssl.CA.cert.filename is configured (along with
proxy.config.ssl.CA.cert.path)
use that file to build the chain
else if proxy.config.ssl.CA.cert.path is configured (and
proxy.config.ssl.CA.cert.filename is NULL)
use the hashed symlinks in that directory to build the chain
else
error out because we don't have the right configuration to build the chain
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-3027) Hashed SSL Intermediate Server Certs not recognized
[
https://issues.apache.org/jira/browse/TS-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Feltner updated TS-3027:
---
Attachment: HashedSSL.patch
Patch to read OpenSSL Hashed Intermediate Certs
Hashed SSL Intermediate Server Certs not recognized
---
Key: TS-3027
URL: https://issues.apache.org/jira/browse/TS-3027
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Steven Feltner
Attachments: HashedSSL.patch
Tested on:
CentOS 6.5 x86_64
trafficserver-5.0.1
Pertinent Config Values:
CONFIG proxy.config.ssl.CA.cert.filename STRING NULL
#CONFIG proxy.config.ssl.CA.cert.filename STRING combined_ca_bundle.crt
CONFIG proxy.config.ssl.CA.cert.path STRING /var/linhosting/users/local
(with and without CA.cert.filename configured)
CONFIG proxy.config.ssl.client.certification_level INT 0
CONFIG proxy.config.ssl.client.verify.server INT 0
c_rehash (from OpenSSL) called from command line to create hash symlinks
Currently, SSL_CTX_load_verify_locations is only called in two cases:
if (params-clientCertLevel != 0) {
and
if (params-clientVerify) {
Attached patch will create a precedence such that:
if ssl_ca_name= is configured in ssl_multicert.config
use that to build the cert chain
else if proxy.config.ssl.CA.cert.filename is configured (along with
proxy.config.ssl.CA.cert.path)
use that file to build the chain
else if proxy.config.ssl.CA.cert.path is configured (and
proxy.config.ssl.CA.cert.filename is NULL)
use the hashed symlinks in that directory to build the chain
else
error out because we don't have the right configuration to build the chain
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-3026) SPDY not forwarding Accept-Encoding headers for Firefox
[ https://issues.apache.org/jira/browse/TS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3026: -- Attachment: (was: TS-3026.diff) SPDY not forwarding Accept-Encoding headers for Firefox --- Key: TS-3026 URL: https://issues.apache.org/jira/browse/TS-3026 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Scott Beardsley Fix For: sometime Attachments: Screen Shot 2014-08-20 at 1.06.42 AM.png Firefox is claiming to be sending the Accept-Encoding header (specifically Accept-Encoding: gzip, deflate) but somewhere it appears to be dropped. I don't see it show up in the logs with http.* debug on. Here is what TS sees: + Incoming Request + -- State Machine Id: 0 GET http://origin.example.com/ HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-language: en-US,en;q=0.5 cookie: cookies dnt: 1 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0 Host: example.com -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3026) SPDY not forwarding Accept-Encoding headers for Firefox
[ https://issues.apache.org/jira/browse/TS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sudheer Vinukonda updated TS-3026: -- Attachment: TS-3026.diff changing the patch to add the header for any method, per discussion with [~jpe...@apache.org] on the IRC SPDY not forwarding Accept-Encoding headers for Firefox --- Key: TS-3026 URL: https://issues.apache.org/jira/browse/TS-3026 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Scott Beardsley Fix For: sometime Attachments: Screen Shot 2014-08-20 at 1.06.42 AM.png, TS-3026.diff Firefox is claiming to be sending the Accept-Encoding header (specifically Accept-Encoding: gzip, deflate) but somewhere it appears to be dropped. I don't see it show up in the logs with http.* debug on. Here is what TS sees: + Incoming Request + -- State Machine Id: 0 GET http://origin.example.com/ HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-language: en-US,en;q=0.5 cookie: cookies dnt: 1 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0 Host: example.com -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (TS-3026) SPDY not forwarding Accept-Encoding headers for Firefox
[ https://issues.apache.org/jira/browse/TS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Brian Geffon reassigned TS-3026: Assignee: Brian Geffon SPDY not forwarding Accept-Encoding headers for Firefox --- Key: TS-3026 URL: https://issues.apache.org/jira/browse/TS-3026 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Scott Beardsley Assignee: Brian Geffon Fix For: sometime Attachments: Screen Shot 2014-08-20 at 1.06.42 AM.png, TS-3026.diff Firefox is claiming to be sending the Accept-Encoding header (specifically Accept-Encoding: gzip, deflate) but somewhere it appears to be dropped. I don't see it show up in the logs with http.* debug on. Here is what TS sees: + Incoming Request + -- State Machine Id: 0 GET http://origin.example.com/ HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-language: en-US,en;q=0.5 cookie: cookies dnt: 1 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0 Host: example.com -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3026) SPDY not forwarding Accept-Encoding headers for Firefox
[ https://issues.apache.org/jira/browse/TS-3026?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14104289#comment-14104289 ] ASF subversion and git services commented on TS-3026: - Commit 7f452ab85039dc32d00a14630550f07651d9aa2b in trafficserver's branch refs/heads/master from [~sudheerv] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=7f452ab ] TS-3026: SPDY not forwarding Accept-Encoding for FF SPDY not forwarding Accept-Encoding headers for Firefox --- Key: TS-3026 URL: https://issues.apache.org/jira/browse/TS-3026 Project: Traffic Server Issue Type: Bug Components: SPDY Reporter: Scott Beardsley Assignee: Brian Geffon Fix For: sometime Attachments: Screen Shot 2014-08-20 at 1.06.42 AM.png, TS-3026.diff Firefox is claiming to be sending the Accept-Encoding header (specifically Accept-Encoding: gzip, deflate) but somewhere it appears to be dropped. I don't see it show up in the logs with http.* debug on. Here is what TS sees: + Incoming Request + -- State Machine Id: 0 GET http://origin.example.com/ HTTP/1.1 accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 accept-language: en-US,en;q=0.5 cookie: cookies dnt: 1 user-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:32.0) Gecko/20100101 Firefox/32.0 Host: example.com -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-3027) Hashed SSL Intermediate Server Certs not recognized
[
https://issues.apache.org/jira/browse/TS-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-3027:
Assignee: James Peach
Hashed SSL Intermediate Server Certs not recognized
---
Key: TS-3027
URL: https://issues.apache.org/jira/browse/TS-3027
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Steven Feltner
Assignee: James Peach
Fix For: 5.1.0
Attachments: HashedSSL.patch
Tested on:
CentOS 6.5 x86_64
trafficserver-5.0.1
Pertinent Config Values:
CONFIG proxy.config.ssl.CA.cert.filename STRING NULL
#CONFIG proxy.config.ssl.CA.cert.filename STRING combined_ca_bundle.crt
CONFIG proxy.config.ssl.CA.cert.path STRING /var/linhosting/users/local
(with and without CA.cert.filename configured)
CONFIG proxy.config.ssl.client.certification_level INT 0
CONFIG proxy.config.ssl.client.verify.server INT 0
c_rehash (from OpenSSL) called from command line to create hash symlinks
Currently, SSL_CTX_load_verify_locations is only called in two cases:
if (params-clientCertLevel != 0) {
and
if (params-clientVerify) {
Attached patch will create a precedence such that:
if ssl_ca_name= is configured in ssl_multicert.config
use that to build the cert chain
else if proxy.config.ssl.CA.cert.filename is configured (along with
proxy.config.ssl.CA.cert.path)
use that file to build the chain
else if proxy.config.ssl.CA.cert.path is configured (and
proxy.config.ssl.CA.cert.filename is NULL)
use the hashed symlinks in that directory to build the chain
else
error out because we don't have the right configuration to build the chain
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-3027) Hashed SSL Intermediate Server Certs not recognized
[
https://issues.apache.org/jira/browse/TS-3027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-3027:
Fix Version/s: 5.1.0
Hashed SSL Intermediate Server Certs not recognized
---
Key: TS-3027
URL: https://issues.apache.org/jira/browse/TS-3027
Project: Traffic Server
Issue Type: Bug
Components: SSL
Reporter: Steven Feltner
Fix For: 5.1.0
Attachments: HashedSSL.patch
Tested on:
CentOS 6.5 x86_64
trafficserver-5.0.1
Pertinent Config Values:
CONFIG proxy.config.ssl.CA.cert.filename STRING NULL
#CONFIG proxy.config.ssl.CA.cert.filename STRING combined_ca_bundle.crt
CONFIG proxy.config.ssl.CA.cert.path STRING /var/linhosting/users/local
(with and without CA.cert.filename configured)
CONFIG proxy.config.ssl.client.certification_level INT 0
CONFIG proxy.config.ssl.client.verify.server INT 0
c_rehash (from OpenSSL) called from command line to create hash symlinks
Currently, SSL_CTX_load_verify_locations is only called in two cases:
if (params-clientCertLevel != 0) {
and
if (params-clientVerify) {
Attached patch will create a precedence such that:
if ssl_ca_name= is configured in ssl_multicert.config
use that to build the cert chain
else if proxy.config.ssl.CA.cert.filename is configured (along with
proxy.config.ssl.CA.cert.path)
use that file to build the chain
else if proxy.config.ssl.CA.cert.path is configured (and
proxy.config.ssl.CA.cert.filename is NULL)
use the hashed symlinks in that directory to build the chain
else
error out because we don't have the right configuration to build the chain
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2954) cache poisoning due to proxy.config.http.use_client_target_addr = 1
[ https://issues.apache.org/jira/browse/TS-2954?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14104321#comment-14104321 ] ASF subversion and git services commented on TS-2954: - Commit 475e40cde4794f6b74c3436c6d00913804dff303 in trafficserver's branch refs/heads/master from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=475e40c ] TS-2954: Fix records so traffic_line works with use_client_target_addr cache poisoning due to proxy.config.http.use_client_target_addr = 1 --- Key: TS-2954 URL: https://issues.apache.org/jira/browse/TS-2954 Project: Traffic Server Issue Type: Bug Components: Cache, DNS, Security, TProxy Reporter: Nikolai Gorchilov Assignee: Susan Hinrichs Priority: Critical Fix For: 5.1.0 Attachments: ts-2954-final.patch, ts-2954-take2.patch, ts-2954.patch Current implementation of proxy.config.http.use_client_target_addr opens a very simple attack vector for cache poisoning in transparent forwarding mode. An attacker (or malware installed on innocent end-user computer) puts a fake IP for popular website like www.google.com or www.facebook.com in hosts file on PC behind the proxy. Once an infected PC requests the webpage in question, a cacheable fake response poisons the cache. In order to prevent such scenarios (as well as [some others|http://www.kb.cert.org/vuls/id/435052]) Squid have implemented a mechanism known as [Host Header Forgery Detection|http://wiki.squid-cache.org/KnowledgeBase/HostHeaderForgery]. In short, while requesting an URL from origin server IP as hinted by the client, proxy makes independent DNS query in parallel in order to determine if client supplied IP belongs to requested domain name. In case of discrepancy between DNS and client IP, the transaction shall be flagged as non-cacheable to avoid possible cache poisoning, while still serving the origin response to the client. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3016) High CPU in 5.0
[
https://issues.apache.org/jira/browse/TS-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14104337#comment-14104337
]
Sudheer Vinukonda commented on TS-3016:
---
fwiw, we have a local patch that adds a configurable setting to disable single
ec/dh key generation options (with a default to OFF). Attaching the patch here,
if it makes sense to pull it into trafficserver.
High CPU in 5.0
---
Key: TS-3016
URL: https://issues.apache.org/jira/browse/TS-3016
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Sudheer Vinukonda
Fix For: 5.1.0
After 5.0 roll out, our production systems are noticing much higher cpu
compared to pre-upgrade ats4 cpu usage.
For example, on some of our hosts running 8 hosts, below is the comparison
before and after the upgade:
{code}
cpu %util: 88.7% (version: ats5)
cpu %util: 70% (version: ats4)
{code}
Running perf top on traffic_server shows most CPU spent in SSL api calls,
initially causing us to suspect any SSL related changes. However, after some
analysis, it looks like the issue might be caused by the changes made in
TS-1365. After reverting the changes in TS-1365, the CPU usage comes back to
pre-upgrade levels again.
{code}
ats5:
--
Samples: 374K of event 'cycles', Event count (approx.): 29126701697
26.44% libcrypto.so.1.0.1e [.] bn_sqr4x_mont
16.26% libcrypto.so.1.0.1e [.] bn_mul_mont --
6.74% libcrypto.so.1.0.1e [.] bn_mul4x_mont_gather5
4.95% libcrypto.so.1.0.1e [.] BN_usub
1.54% libcrypto.so.1.0.1e [.] sha256_block_data_order
1.37% libcrypto.so.1.0.1e [.] BN_mod_mul_montgomery
80.89 libcrypto.so.1.0.1e
7.09 traffic_server
5.02 [kernel]
2.71 libc-2.12.so
0.59 libpthread-2.12.so
0.42 libssl.so.1.0.1e
0.32 libtsutil.so.5
0.32 [bnx2]
0.02 libstdc++.so.6.0.13
0.02 libpcre.so.0.0.1
0.01 quick_filter.so
0.01 libtcl8.5.so
0.01 librt-2.12.so
0.01 [kernel].vsyscall_fn
0.01 [kernel].vsyscall_1
0 regex_remap.so
0 libresolv-2.12.so
0 libgtlocip.so.1.7.4.B86
0 header_rewrite.so
0 conf_remap.so
0 [sd_mod]
0 [mpt2sas]
0 [kernel].vsyscall_0
0 [jbd]
0 [ipv6]
0 [ext3]
0 [dm_mod]
ats4:
-
Samples: 249K of event 'cycles', Event count (approx.): 18282595621
39.34% libcrypto.so.1.0.1e [.] bn_sqr4x_mont
10.23% libcrypto.so.1.0.1e [.] bn_mul4x_mont_gather5
6.25% libcrypto.so.1.0.1e [.] bn_mul_mont --
2.19% libcrypto.so.1.0.1e [.] sha256_block_data_order
2.03% libcrypto.so.1.0.1e [.] BN_usub
1.50% [kernel] [k] find_busiest_group
1.08% libcrypto.so.1.0.1e [.] sha1_block_data_order_ssse3
80.93 libcrypto.so.1.0.1e
6.9 [kernel]
4.96 traffic_server
3 libc-2.12.so
0.84 libpthread-2.12.so
0.81 libssl.so.1.0.1e
0.38 [bnx2]
0.32 libtsutil.so.4
0.02 libtcl8.5.so
0.02 librt-2.12.so
0.02 libpcre.so.0.0.1
0.02 [kernel].vsyscall_fn
0.01 quick_filter.so
0.01 [kernel].vsyscall_1
0.01 [kernel].vsyscall_0
0 regex_remap.so
0 libstdc++.so.6.0.13
0 libresolv-2.12.so
0 header_rewrite.so
0 conf_remap.so
0 [sd_mod]
0 [mpt2sas]
0 [jbd]
0 [ipv6]
0 [ext3]
0 [dm_mod]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-3016) High CPU in 5.0
[
https://issues.apache.org/jira/browse/TS-3016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sudheer Vinukonda updated TS-3016:
--
Attachment: TS-3016.diff
High CPU in 5.0
---
Key: TS-3016
URL: https://issues.apache.org/jira/browse/TS-3016
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: Sudheer Vinukonda
Fix For: 5.1.0
Attachments: TS-3016.diff
After 5.0 roll out, our production systems are noticing much higher cpu
compared to pre-upgrade ats4 cpu usage.
For example, on some of our hosts running 8 hosts, below is the comparison
before and after the upgade:
{code}
cpu %util: 88.7% (version: ats5)
cpu %util: 70% (version: ats4)
{code}
Running perf top on traffic_server shows most CPU spent in SSL api calls,
initially causing us to suspect any SSL related changes. However, after some
analysis, it looks like the issue might be caused by the changes made in
TS-1365. After reverting the changes in TS-1365, the CPU usage comes back to
pre-upgrade levels again.
{code}
ats5:
--
Samples: 374K of event 'cycles', Event count (approx.): 29126701697
26.44% libcrypto.so.1.0.1e [.] bn_sqr4x_mont
16.26% libcrypto.so.1.0.1e [.] bn_mul_mont --
6.74% libcrypto.so.1.0.1e [.] bn_mul4x_mont_gather5
4.95% libcrypto.so.1.0.1e [.] BN_usub
1.54% libcrypto.so.1.0.1e [.] sha256_block_data_order
1.37% libcrypto.so.1.0.1e [.] BN_mod_mul_montgomery
80.89 libcrypto.so.1.0.1e
7.09 traffic_server
5.02 [kernel]
2.71 libc-2.12.so
0.59 libpthread-2.12.so
0.42 libssl.so.1.0.1e
0.32 libtsutil.so.5
0.32 [bnx2]
0.02 libstdc++.so.6.0.13
0.02 libpcre.so.0.0.1
0.01 quick_filter.so
0.01 libtcl8.5.so
0.01 librt-2.12.so
0.01 [kernel].vsyscall_fn
0.01 [kernel].vsyscall_1
0 regex_remap.so
0 libresolv-2.12.so
0 libgtlocip.so.1.7.4.B86
0 header_rewrite.so
0 conf_remap.so
0 [sd_mod]
0 [mpt2sas]
0 [kernel].vsyscall_0
0 [jbd]
0 [ipv6]
0 [ext3]
0 [dm_mod]
ats4:
-
Samples: 249K of event 'cycles', Event count (approx.): 18282595621
39.34% libcrypto.so.1.0.1e [.] bn_sqr4x_mont
10.23% libcrypto.so.1.0.1e [.] bn_mul4x_mont_gather5
6.25% libcrypto.so.1.0.1e [.] bn_mul_mont --
2.19% libcrypto.so.1.0.1e [.] sha256_block_data_order
2.03% libcrypto.so.1.0.1e [.] BN_usub
1.50% [kernel] [k] find_busiest_group
1.08% libcrypto.so.1.0.1e [.] sha1_block_data_order_ssse3
80.93 libcrypto.so.1.0.1e
6.9 [kernel]
4.96 traffic_server
3 libc-2.12.so
0.84 libpthread-2.12.so
0.81 libssl.so.1.0.1e
0.38 [bnx2]
0.32 libtsutil.so.4
0.02 libtcl8.5.so
0.02 librt-2.12.so
0.02 libpcre.so.0.0.1
0.02 [kernel].vsyscall_fn
0.01 quick_filter.so
0.01 [kernel].vsyscall_1
0.01 [kernel].vsyscall_0
0 regex_remap.so
0 libstdc++.so.6.0.13
0 libresolv-2.12.so
0 header_rewrite.so
0 conf_remap.so
0 [sd_mod]
0 [mpt2sas]
0 [jbd]
0 [ipv6]
0 [ext3]
0 [dm_mod]
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2970) Multiple crashes when using tr-pass
[
https://issues.apache.org/jira/browse/TS-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-2970:
Assignee: Susan Hinrichs (was: Alan M. Carroll)
Multiple crashes when using tr-pass
---
Key: TS-2970
URL: https://issues.apache.org/jira/browse/TS-2970
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Affects Versions: 5.0.0, 5.0.1
Reporter: Nikolai Gorchilov
Assignee: Susan Hinrichs
Fix For: sometime
ATS 5.0.1 Running under Linux 3+ kernel in TPROXY mode.
Same configuration runs without a single crash for weeks, but in the moment I
enable tr-pass (8081:ip-in=127.0.0.1:tr-ful:tr-pass) on server_ports I get
many crashes in matter of seconds to minutes after starting the ATS:
{noformat}
FATAL: HttpSM.cc:2714: failed assert `event == HTTP_TUNNEL_EVENT_DONE`
/z/bin/traffic_server - STACK TRACE:
/z/lib/libtsutil.so.5(ink_fatal_die+0x0)[0x2b52382e8067]
/z/lib/libtsutil.so.5(ink_get_rand()+0x0)[0x2b52382e6b28]
/z/bin/traffic_server(HttpSM::tunnel_handler(int, void*)+0x148)[0x5cf9aa]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0x333)[0x5cebeb]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server(CheckConnect::handle_connect(int,
Event*)+0x2f0)[0x74313c]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server[0x743c82]
/z/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
EThread*)+0x389)[0x7449c3]
/z/bin/traffic_server(write_to_net(NetHandler*, UnixNetVConnection*,
EThread*)+0x79)[0x744638]
/z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x6f3)[0x73dc21]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x11e)[0x7664ca]
/z/bin/traffic_server(EThread::execute()+0x45b)[0x766aa1]
/z/bin/traffic_server[0x76598f]
/lib64/libpthread.so.0(+0x7034)[0x2b52398f4034]
/lib64/libc.so.6(clone+0x6d)[0x2b523a63eb5d]
{noformat}
{noformat}
FATAL: HttpSM.cc:1687: failed assert `0`
/z/bin/traffic_server - STACK TRACE:
/z/lib/libtsutil.so.5(+0x1e837)[0x2b6545caa837]
/z/lib/libtsutil.so.5(+0x1d51f)[0x2b6545ca951f]
/z/bin/traffic_server(HttpSM::state_http_server_open(int,
void*)+0xfd)[0x5a13cd]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x59ac88]
/z/bin/traffic_server[0x65313a]
/z/bin/traffic_server(HostDBContinuation::probeEvent(int,
Event*)+0x27a)[0x65967a]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x736071]
/z/bin/traffic_server(EThread::execute()+0x2fb)[0x73692b]
/z/bin/traffic_server[0x73530a]
/lib64/libpthread.so.0(+0x7034)[0x2b65472b0034]
/lib64/libc.so.6(clone+0x6d)[0x2b6547ffab5d]
{noformat}
{noformat}
FATAL: HttpTunnel.cc:554: failed assert `active == false`
/z/bin/traffic_server - STACK TRACE:
/z/lib/libtsutil.so.5(+0x1e837)[0x2b679373e837]
/z/lib/libtsutil.so.5(+0x1d51f)[0x2b679373d51f]
/z/bin/traffic_server[0x5d660f]
/z/bin/traffic_server(HttpSM::kill_this()+0x674)[0x59a974]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0x148)[0x59acf8]
/z/bin/traffic_server(CheckConnect::handle_connect(int,
Event*)+0x119)[0x70d659]
/z/bin/traffic_server(UnixNetVConnection::mainEvent(int,
Event*)+0x3f0)[0x716640]
/z/bin/traffic_server(InactivityCop::check_inactivity(int,
Event*)+0x275)[0x708045]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x736071]
/z/bin/traffic_server(EThread::execute()+0x2fb)[0x73692b]
/z/bin/traffic_server[0x73530a]
/lib64/libpthread.so.0(+0x7034)[0x2b6794d44034]
/lib64/libc.so.6(clone+0x6d)[0x2b6795a8eb5d]
{noformat}
My configure options other than layout-related are:
{noformat}
--with-group=proxy \
--with-xml=libxml2 \
--disable-static \
--disable-static-libts \
--disable-spdy \
--enable-interim-cache \
--enable-tproxy \
--enable-hwloc \
--enable-experimental-plugins \
--enable-example-plugins
{noformat}
P.S. Report updated due to some --enable-debug related crashes, that weren't
connected to tr-pass at all
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2993) ats_speed: update towards 1.8.31.4-stable
[ https://issues.apache.org/jira/browse/TS-2993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14104565#comment-14104565 ] ASF subversion and git services commented on TS-2993: - Commit 335cbf4100e79c9333a4a4d06cce1d17149c4935 in trafficserver's branch refs/heads/master from [~oschaaf] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=335cbf4 ] ats_speed: upgrade from 1.7.30.4 to 1.8.31.4 Upgrade to the latest greatest PSOL version Fixes TS-2993 ats_speed: update towards 1.8.31.4-stable - Key: TS-2993 URL: https://issues.apache.org/jira/browse/TS-2993 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Otto van der Schaaf Assignee: Otto van der Schaaf Fix For: sometime A new stable mod_pagespeed release was announced yesterday[1]. Upgrade ats_speed to use the latest and greatest stable PageSpeed optimization libraries. [1] https://groups.google.com/forum/?utm_medium=emailutm_source=footer#!msg/mod-pagespeed-discuss/Qng-Da0IwcY/Y63-WlDHg5wJ -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3005) Rename ats_speed plugin - ats_pagespeed
[ https://issues.apache.org/jira/browse/TS-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14104566#comment-14104566 ] ASF subversion and git services commented on TS-3005: - Commit 1fe51067bfa77ff2141d6988d65d7c36976da832 in trafficserver's branch refs/heads/master from [~oschaaf] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1fe5106 ] ats_pagespeed: rename ats_speed - ats_pagespeed Fixes TS-3005 Rename ats_speed plugin - ats_pagespeed Key: TS-3005 URL: https://issues.apache.org/jira/browse/TS-3005 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Otto van der Schaaf Assignee: Otto van der Schaaf Fix For: 5.1.0 Renaming the plugin to ats_pagespeed just was approved by Google. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Work started] (TS-2970) Multiple crashes when using tr-pass
[
https://issues.apache.org/jira/browse/TS-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Work on TS-2970 started by Susan Hinrichs.
Multiple crashes when using tr-pass
---
Key: TS-2970
URL: https://issues.apache.org/jira/browse/TS-2970
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Affects Versions: 5.0.0, 5.0.1
Reporter: Nikolai Gorchilov
Assignee: Susan Hinrichs
Fix For: sometime
ATS 5.0.1 Running under Linux 3+ kernel in TPROXY mode.
Same configuration runs without a single crash for weeks, but in the moment I
enable tr-pass (8081:ip-in=127.0.0.1:tr-ful:tr-pass) on server_ports I get
many crashes in matter of seconds to minutes after starting the ATS:
{noformat}
FATAL: HttpSM.cc:2714: failed assert `event == HTTP_TUNNEL_EVENT_DONE`
/z/bin/traffic_server - STACK TRACE:
/z/lib/libtsutil.so.5(ink_fatal_die+0x0)[0x2b52382e8067]
/z/lib/libtsutil.so.5(ink_get_rand()+0x0)[0x2b52382e6b28]
/z/bin/traffic_server(HttpSM::tunnel_handler(int, void*)+0x148)[0x5cf9aa]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0x333)[0x5cebeb]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server(CheckConnect::handle_connect(int,
Event*)+0x2f0)[0x74313c]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server[0x743c82]
/z/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
EThread*)+0x389)[0x7449c3]
/z/bin/traffic_server(write_to_net(NetHandler*, UnixNetVConnection*,
EThread*)+0x79)[0x744638]
/z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x6f3)[0x73dc21]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x11e)[0x7664ca]
/z/bin/traffic_server(EThread::execute()+0x45b)[0x766aa1]
/z/bin/traffic_server[0x76598f]
/lib64/libpthread.so.0(+0x7034)[0x2b52398f4034]
/lib64/libc.so.6(clone+0x6d)[0x2b523a63eb5d]
{noformat}
{noformat}
FATAL: HttpSM.cc:1687: failed assert `0`
/z/bin/traffic_server - STACK TRACE:
/z/lib/libtsutil.so.5(+0x1e837)[0x2b6545caa837]
/z/lib/libtsutil.so.5(+0x1d51f)[0x2b6545ca951f]
/z/bin/traffic_server(HttpSM::state_http_server_open(int,
void*)+0xfd)[0x5a13cd]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x59ac88]
/z/bin/traffic_server[0x65313a]
/z/bin/traffic_server(HostDBContinuation::probeEvent(int,
Event*)+0x27a)[0x65967a]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x736071]
/z/bin/traffic_server(EThread::execute()+0x2fb)[0x73692b]
/z/bin/traffic_server[0x73530a]
/lib64/libpthread.so.0(+0x7034)[0x2b65472b0034]
/lib64/libc.so.6(clone+0x6d)[0x2b6547ffab5d]
{noformat}
{noformat}
FATAL: HttpTunnel.cc:554: failed assert `active == false`
/z/bin/traffic_server - STACK TRACE:
/z/lib/libtsutil.so.5(+0x1e837)[0x2b679373e837]
/z/lib/libtsutil.so.5(+0x1d51f)[0x2b679373d51f]
/z/bin/traffic_server[0x5d660f]
/z/bin/traffic_server(HttpSM::kill_this()+0x674)[0x59a974]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0x148)[0x59acf8]
/z/bin/traffic_server(CheckConnect::handle_connect(int,
Event*)+0x119)[0x70d659]
/z/bin/traffic_server(UnixNetVConnection::mainEvent(int,
Event*)+0x3f0)[0x716640]
/z/bin/traffic_server(InactivityCop::check_inactivity(int,
Event*)+0x275)[0x708045]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x736071]
/z/bin/traffic_server(EThread::execute()+0x2fb)[0x73692b]
/z/bin/traffic_server[0x73530a]
/lib64/libpthread.so.0(+0x7034)[0x2b6794d44034]
/lib64/libc.so.6(clone+0x6d)[0x2b6795a8eb5d]
{noformat}
My configure options other than layout-related are:
{noformat}
--with-group=proxy \
--with-xml=libxml2 \
--disable-static \
--disable-static-libts \
--disable-spdy \
--enable-interim-cache \
--enable-tproxy \
--enable-hwloc \
--enable-experimental-plugins \
--enable-example-plugins
{noformat}
P.S. Report updated due to some --enable-debug related crashes, that weren't
connected to tr-pass at all
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2970) Multiple crashes when using tr-pass
[
https://issues.apache.org/jira/browse/TS-2970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Susan Hinrichs updated TS-2970:
---
Attachment: ts-2970.patch
This patch has been tested against 5.0.1. I still need to move my branch up to
master.
It is definitely fixing a problem. I'm not sure it is the problem that you
are seeing. When setting up the blind tunnel, there is a gap before the
HttpTunnel data structure is ready to move data. The incoming connection read
events were not being turned off. So if you were unlucky in the timing the
Http StateMachine may read any waiting data before the HttpTunnel is setup. In
that case, the read request logic is run again, which is a bad thing.
Fixed this by turning off events on the incoming connection. It appears that
the HttpTunnel startup logic turns the events back on.
I was able to reproduce this problem my netcatting files longer than a http
header size through Traffic Server. In my case they were html files I happened
to have sitting on my test client.
I was seeing (!s-hdr_info.server_request.valid()) assert at the top of
HttpTransact::HandleRequest() go. Not the same as the asserts you reported,
but in a more complicated operational environment, going through the request
setup twice could cause a fair number of problems.
Multiple crashes when using tr-pass
---
Key: TS-2970
URL: https://issues.apache.org/jira/browse/TS-2970
Project: Traffic Server
Issue Type: Bug
Components: Core, HTTP
Affects Versions: 5.0.0, 5.0.1
Reporter: Nikolai Gorchilov
Assignee: Susan Hinrichs
Fix For: sometime
Attachments: ts-2970.patch
ATS 5.0.1 Running under Linux 3+ kernel in TPROXY mode.
Same configuration runs without a single crash for weeks, but in the moment I
enable tr-pass (8081:ip-in=127.0.0.1:tr-ful:tr-pass) on server_ports I get
many crashes in matter of seconds to minutes after starting the ATS:
{noformat}
FATAL: HttpSM.cc:2714: failed assert `event == HTTP_TUNNEL_EVENT_DONE`
/z/bin/traffic_server - STACK TRACE:
/z/lib/libtsutil.so.5(ink_fatal_die+0x0)[0x2b52382e8067]
/z/lib/libtsutil.so.5(ink_get_rand()+0x0)[0x2b52382e6b28]
/z/bin/traffic_server(HttpSM::tunnel_handler(int, void*)+0x148)[0x5cf9aa]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0x333)[0x5cebeb]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server(CheckConnect::handle_connect(int,
Event*)+0x2f0)[0x74313c]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server[0x743c82]
/z/bin/traffic_server(write_to_net_io(NetHandler*, UnixNetVConnection*,
EThread*)+0x389)[0x7449c3]
/z/bin/traffic_server(write_to_net(NetHandler*, UnixNetVConnection*,
EThread*)+0x79)[0x744638]
/z/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x6f3)[0x73dc21]
/z/bin/traffic_server(Continuation::handleEvent(int, void*)+0x68)[0x4f089a]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x11e)[0x7664ca]
/z/bin/traffic_server(EThread::execute()+0x45b)[0x766aa1]
/z/bin/traffic_server[0x76598f]
/lib64/libpthread.so.0(+0x7034)[0x2b52398f4034]
/lib64/libc.so.6(clone+0x6d)[0x2b523a63eb5d]
{noformat}
{noformat}
FATAL: HttpSM.cc:1687: failed assert `0`
/z/bin/traffic_server - STACK TRACE:
/z/lib/libtsutil.so.5(+0x1e837)[0x2b6545caa837]
/z/lib/libtsutil.so.5(+0x1d51f)[0x2b6545ca951f]
/z/bin/traffic_server(HttpSM::state_http_server_open(int,
void*)+0xfd)[0x5a13cd]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x59ac88]
/z/bin/traffic_server[0x65313a]
/z/bin/traffic_server(HostDBContinuation::probeEvent(int,
Event*)+0x27a)[0x65967a]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x736071]
/z/bin/traffic_server(EThread::execute()+0x2fb)[0x73692b]
/z/bin/traffic_server[0x73530a]
/lib64/libpthread.so.0(+0x7034)[0x2b65472b0034]
/lib64/libc.so.6(clone+0x6d)[0x2b6547ffab5d]
{noformat}
{noformat}
FATAL: HttpTunnel.cc:554: failed assert `active == false`
/z/bin/traffic_server - STACK TRACE:
/z/lib/libtsutil.so.5(+0x1e837)[0x2b679373e837]
/z/lib/libtsutil.so.5(+0x1d51f)[0x2b679373d51f]
/z/bin/traffic_server[0x5d660f]
/z/bin/traffic_server(HttpSM::kill_this()+0x674)[0x59a974]
/z/bin/traffic_server(HttpSM::main_handler(int, void*)+0x148)[0x59acf8]
/z/bin/traffic_server(CheckConnect::handle_connect(int,
Event*)+0x119)[0x70d659]
/z/bin/traffic_server(UnixNetVConnection::mainEvent(int,
Event*)+0x3f0)[0x716640]
/z/bin/traffic_server(InactivityCop::check_inactivity(int,
Event*)+0x275)[0x708045]
/z/bin/traffic_server(EThread::process_event(Event*, int)+0x91)[0x736071]
/z/bin/traffic_server(EThread::execute()+0x2fb)[0x73692b]
/z/bin/traffic_server[0x73530a]
/lib64/libpthread.so.0(+0x7034)[0x2b6794d44034]
