Build failed in Jenkins: tsqa-master #720

[jenkins]

See 

Changes:

[zizhang] TS-3779: Body Factory: support per host error pages

[zizhang] TS-3779: Body Factory: support per host error pages: TESTS

[zizhang] TS-3779: Body Factory: support per host error pages: DOCUMENTATION

--
[...truncated 510 lines...]
INFO 2015-07-23 04:21:58,970 - sending data back to the client
INFO 2015-07-23 04:22:02,975 - sending data back to the client
ok
test_chunked_keepalive_server (test_chunked.TestChunked) ... INFO 2015-07-23 
04:22:06,980 - sending data back to the client
INFO 2015-07-23 04:22:09,985 - sending data back to the client
ok
Test that the origin does in fact support keepalive ... INFO 2015-07-23 
04:22:10,990 - sending data back to the client
INFO 2015-07-23 04:22:13,993 - sending data back to the client
INFO 2015-07-23 04:22:14,996 - sending data back to the client
INFO 2015-07-23 04:22:16,998 - Client disconnected
INFO 2015-07-23 04:22:17,400 - sending data back to the client
INFO 2015-07-23 04:22:17,802 - sending data back to the client
INFO 2015-07-23 04:22:19,803 - Client disconnected
INFO 2015-07-23 04:22:21,807 - sending data back to the client
ok
INFO 2015-07-23 04:22:23,818 - Client disconnected
INFO 2015-07-23 04:22:24,002 - Environment prefix is /tmp/tsqa.env.fVkKOy
INFO 2015-07-23 04:22:25,812 - Client disconnected
Verify that we get 502s from an origin which just did a bind ... ok
Verify that we get 200s from origins that delayed_accept_after_connect ... ok
Verify that we get 504s from origins that die_on_connect ... ok
Verify that we get 502s from origins that bind + listen ... ok
Verify that we get 504s from origins that return a partial_response ... FAIL
Verify that we get 200s from origins that reset_after_accept ... FAIL
INFO 2015-07-23 04:22:34,297 - Environment prefix is /tmp/tsqa.env.JRqoMn
test_log_field (test_custom_log.TestCustomLogField) ... ok
INFO 2015-07-23 04:24:17,822 - Environment prefix is /tmp/tsqa.env.5v2i2l
test_default_404 (test_example.TestBootstrap) ... ok
Test that traffic_line works, and verify that the values for proxy.config ... ok
INFO 2015-07-23 04:24:48,962 - Starting build 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-07-23 04:26:08,108 - Build completed 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-07-23 04:26:08,175 - Environment prefix is /tmp/tsqa.env.q5hoWm
test_spdy (test_example.TestConfigureFlags) ... ok
INFO 2015-07-23 04:26:11,582 - Environment prefix is /tmp/tsqa.env.vfZ9DA
test_basic_proxy (test_example.TestDynamicHTTPEndpointCase) ... 127.0.0.1 - - 
[23/Jul/2015 04:26:14] "GET /test HTTP/1.1" 404 0
ok
INFO 2015-07-23 04:26:14,991 - Environment prefix is /tmp/tsqa.env.DSMJCM
test_logs_exist (test_example.TestLogRefCounting) ... 127.0.0.1 - - 
[23/Jul/2015 04:26:18] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [23/Jul/2015 04:26:18] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [23/Jul/2015 04:26:18] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [23/Jul/2015 04:26:18] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [23/Jul/2015 04:26:18] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [23/Jul/2015 04:26:18] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [23/Jul/2015 04:26:18] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [23/Jul/2015 04:26:18] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [23/Jul/2015 04:26:18] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [23/Jul/2015 04:26:18] "GET / HTTP/1.1" 404 0
FAIL
INFO 2015-07-23 04:26:28,478 - Environment prefix is /tmp/tsqa.env.j5I3KZ
test_logs_exist (test_example.TestLogs) ... FAIL
SKIP: Skip the entire class
INFO 2015-07-23 04:26:41,926 - Environment prefix is /tmp/tsqa.env.53C4ic
test_basic_intercept (test_example.TestServerIntercept) ... 127.0.0.1 - - 
[23/Jul/2015 04:26:45] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [23/Jul/2015 04:26:45] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [23/Jul/2015 04:26:45] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [23/Jul/2015 04:26:45] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [23/Jul/2015 04:26:45] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [23/Jul/2015 04:26:45] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [23/Jul/2015 04:26:45] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [23/Jul/2015 04:26:45] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [23/Jul/2015 04:26:45] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [23/Jul/2015 04:26:45] "GET / HTTP/1.1" 200 5
ok
INFO 2015-07-23 04:26:45,372 - Environment prefix is /tmp/tsqa.env.Rv8OH7
test_lookup_timeout (test_hostdb.TestHostDBFailedDNS) ... ok
INFO 2015-07-23 04:26:50,798 - Environment prefix is /tmp/tsqa.env.SbOk6D
Test basic fnctionality of hosts files ... ok
Test that changes to hosts file get loaded within host_file.interval ... ok
INFO 

Build failed in Jenkins: tsqa-master #719

[jenkins]

See 

Changes:

[zizhang] TS-3780: Logs_xml: add logging field for incoming (interface) ip.

[zizhang] TS-3780: Logs_xml: add logging field for incoming (interface) ip. 
TESTS

[zizhang] TS-3780: Logs_xml: add logging field for incoming (interface) ip. 
DOCUMENTATION

--
[...truncated 507 lines...]
INFO 2015-07-23 04:13:12,391 - sending data back to the client
INFO 2015-07-23 04:13:16,396 - sending data back to the client
ok
test_chunked_keepalive_server (test_chunked.TestChunked) ... INFO 2015-07-23 
04:13:20,401 - sending data back to the client
INFO 2015-07-23 04:13:23,406 - sending data back to the client
ok
Test that the origin does in fact support keepalive ... INFO 2015-07-23 
04:13:24,410 - sending data back to the client
INFO 2015-07-23 04:13:27,415 - sending data back to the client
INFO 2015-07-23 04:13:28,418 - sending data back to the client
INFO 2015-07-23 04:13:30,417 - Client disconnected
INFO 2015-07-23 04:13:30,822 - sending data back to the client
INFO 2015-07-23 04:13:31,224 - sending data back to the client
INFO 2015-07-23 04:13:33,225 - Client disconnected
INFO 2015-07-23 04:13:35,228 - sending data back to the client
ok
INFO 2015-07-23 04:13:37,239 - Client disconnected
INFO 2015-07-23 04:13:37,433 - Environment prefix is /tmp/tsqa.env.rC6cED
INFO 2015-07-23 04:13:39,234 - Client disconnected
Verify that we get 502s from an origin which just did a bind ... ok
Verify that we get 200s from origins that delayed_accept_after_connect ... ok
Verify that we get 504s from origins that die_on_connect ... ok
Verify that we get 502s from origins that bind + listen ... ok
Verify that we get 504s from origins that return a partial_response ... FAIL
Verify that we get 200s from origins that reset_after_accept ... FAIL
INFO 2015-07-23 04:13:48,717 - Environment prefix is /tmp/tsqa.env.XwBBJX
test_log_field (test_custom_log.TestCustomLogField) ... ok
INFO 2015-07-23 04:15:32,217 - Environment prefix is /tmp/tsqa.env.VksXIr
test_default_404 (test_example.TestBootstrap) ... ok
Test that traffic_line works, and verify that the values for proxy.config ... ok
INFO 2015-07-23 04:16:01,822 - Starting build 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-07-23 04:17:11,401 - Build completed 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-07-23 04:17:11,466 - Environment prefix is /tmp/tsqa.env.K_0DfG
test_spdy (test_example.TestConfigureFlags) ... ok
INFO 2015-07-23 04:17:14,869 - Environment prefix is /tmp/tsqa.env.moR8T1
test_basic_proxy (test_example.TestDynamicHTTPEndpointCase) ... 127.0.0.1 - - 
[23/Jul/2015 04:17:18] "GET /test HTTP/1.1" 404 0
ok
INFO 2015-07-23 04:17:18,278 - Environment prefix is /tmp/tsqa.env.3F0DxV
test_logs_exist (test_example.TestLogRefCounting) ... 127.0.0.1 - - 
[23/Jul/2015 04:17:21] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [23/Jul/2015 04:17:21] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [23/Jul/2015 04:17:21] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [23/Jul/2015 04:17:21] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [23/Jul/2015 04:17:21] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [23/Jul/2015 04:17:21] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [23/Jul/2015 04:17:21] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [23/Jul/2015 04:17:21] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [23/Jul/2015 04:17:21] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [23/Jul/2015 04:17:21] "GET / HTTP/1.1" 404 0
FAIL
INFO 2015-07-23 04:17:31,742 - Environment prefix is /tmp/tsqa.env.H6f5Ik
test_logs_exist (test_example.TestLogs) ... FAIL
SKIP: Skip the entire class
INFO 2015-07-23 04:17:45,193 - Environment prefix is /tmp/tsqa.env.XzmYyJ
test_basic_intercept (test_example.TestServerIntercept) ... 127.0.0.1 - - 
[23/Jul/2015 04:17:48] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [23/Jul/2015 04:17:48] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [23/Jul/2015 04:17:48] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [23/Jul/2015 04:17:48] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [23/Jul/2015 04:17:48] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [23/Jul/2015 04:17:48] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [23/Jul/2015 04:17:48] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [23/Jul/2015 04:17:48] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [23/Jul/2015 04:17:48] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [23/Jul/2015 04:17:48] "GET / HTTP/1.1" 200 5
ok
INFO 2015-07-23 04:17:48,640 - Environment prefix is /tmp/tsqa.env.vAR_bd
test_lookup_timeout (test_hostdb.TestHostDBFailedDNS) ... ok
INFO 2015-07-23 04:17:54,080 - Environment prefix is /tmp/tsqa.env.kHZi5q
Test basic fnctionality of hosts files ... ok
Test that changes to hosts file get loa

[jira] [Commented] (TS-3754) IOBuffer memory leak

[Oknet Xu (JIRA)]

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

Oknet Xu commented on TS-3754:
--

Does it needs a back port to every released version ？


> IOBuffer memory leak
> 
>
> Key: TS-3754
> URL: https://issues.apache.org/jira/browse/TS-3754
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Oknet Xu
>Assignee: Alan M. Carroll
>Priority: Critical
> Fix For: 6.1.0
>
>
> the pointer `_end_buf` exceed the IOBufferData->_data size if offset > 0
> patch at below
> {code}
> diff --git a/iocore/eventsystem/P_IOBuffer.h b/iocore/eventsystem/P_IOBuffer.h
> index 3b8c323..71de17d 100644
> --- a/iocore/eventsystem/P_IOBuffer.h
> +++ b/iocore/eventsystem/P_IOBuffer.h
> @@ -477,7 +477,7 @@ IOBufferBlock::set(IOBufferData *d, int64_t len, int64_t 
> offset)
>data = d;
>_start = buf() + offset;
>_end = _start + len;
> -  _buf_end = _start + d->block_size();
> +  _buf_end = buf() + d->block_size();
>  }
>  
>  TS_INLINE void
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Build failed in Jenkins: clang-format #52

[jenkins]

See 

Changes:

[zizhang] TS-3779: Body Factory: support per host error pages

[zizhang] TS-3779: Body Factory: support per host error pages: TESTS

[zizhang] TS-3779: Body Factory: support per host error pages: DOCUMENTATION

--
[...truncated 4299 lines...]
+ clang-format -i src/proxy/http2/HTTP2.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2ClientSession.h
src/proxy/http2/Http2ClientSession.h
+ clang-format -i src/proxy/http2/Http2ClientSession.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HPACK.h
src/proxy/http2/HPACK.h
+ clang-format -i src/proxy/http2/HPACK.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HTTP2.h
src/proxy/http2/HTTP2.h
+ clang-format -i src/proxy/http2/HTTP2.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HuffmanCodec.cc
src/proxy/http2/HuffmanCodec.cc
+ clang-format -i src/proxy/http2/HuffmanCodec.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2SessionAccept.cc
src/proxy/http2/Http2SessionAccept.cc
+ clang-format -i src/proxy/http2/Http2SessionAccept.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HPACK.cc
src/proxy/http2/HPACK.cc
+ clang-format -i src/proxy/http2/HPACK.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/Main.cc
src/proxy/Main.cc
+ clang-format -i src/proxy/Main.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/UDPAPIClientTest.cc
src/proxy/UDPAPIClientTest.cc
+ clang-format -i src/proxy/UDPAPIClientTest.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/Plugin.cc
src/proxy/Plugin.cc
+ clang-format -i src/proxy/Plugin.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/TestClock.cc
src/proxy/TestClock.cc
+ clang-format -i src/proxy/TestClock.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/UDPAPIClientTest.h
src/proxy/UDPAPIClientTest.h
+ clang-format -i src/proxy/UDPAPIClientTest.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/ICPProcessor.h
src/proxy/ICPProcessor.h
+ clang-format -i src/proxy/ICPProcessor.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/InkAPITest.cc
src/proxy/InkAPITest.cc
+ clang-format -i src/proxy/InkAPITest.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/EventName.cc
src/proxy/EventName.cc
+ clang-format -i src/proxy/EventName.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/CompletionUtil.h
src/proxy/CompletionUtil.h
+ clang-format -i src/proxy/CompletionUtil.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/ReverseProxy.h
src/proxy/ReverseProxy.h
+ clang-format -i src/proxy/ReverseProxy.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/Prefetch.cc
src/proxy/Prefetch.cc
+ clang-format -i src/proxy/Prefetch.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/TestPreProc.h
src/proxy/TestPreProc.h
+ clang-format -i src/proxy/TestPreProc.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/InkPool_r.h
src/proxy/InkPool_r.h
+ clang-format -i src/proxy/InkPool_r.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/DynamicStats.h
src/proxy/DynamicStats.h
+ clang-format -i src/proxy/DynamicStats.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/StatSystem.cc
src/proxy/StatSystem.cc
+ clang-format -i src/proxy/StatSystem.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/StatPages.h
src/proxy/StatPages.h
+ clang-format -i src/proxy/StatPages.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/CacheControl.cc
src/proxy/CacheControl.cc
+ clang-format -i src/proxy/CacheControl.cc
+ for f in '`find s

Jenkins build is still unstable: tsqa-lint #341

[jenkins]

See 

[jira] [Commented] (TS-3779) Body Factory: support per hosts error pages.

[ASF subversion and git services (JIRA)]

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

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

Commit 09beb115c52802bab2967bde2ac9c7cdc14fd68d in trafficserver's branch 
refs/heads/master from [~zhangzizhong]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=09beb11 ]

TS-3779: Body Factory: support per host error pages


> Body Factory: support per hosts error pages.
> 
>
> Key: TS-3779
> URL: https://issues.apache.org/jira/browse/TS-3779
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Core
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>  Labels: review
> Fix For: 6.0.0
>
>
> Body Factory should support per-host error pages as it supports per-language 
> error pages today.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3779) Body Factory: support per hosts error pages.

[ASF subversion and git services (JIRA)]

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

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

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

TS-3779: Body Factory: support per host error pages: DOCUMENTATION


> Body Factory: support per hosts error pages.
> 
>
> Key: TS-3779
> URL: https://issues.apache.org/jira/browse/TS-3779
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Core
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>  Labels: review
> Fix For: 6.0.0
>
>
> Body Factory should support per-host error pages as it supports per-language 
> error pages today.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3779) Body Factory: support per hosts error pages.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3779:


Github user asfgit closed the pull request at:

https://github.com/apache/trafficserver/pull/257


> Body Factory: support per hosts error pages.
> 
>
> Key: TS-3779
> URL: https://issues.apache.org/jira/browse/TS-3779
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Core
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>  Labels: review
> Fix For: 6.0.0
>
>
> Body Factory should support per-host error pages as it supports per-language 
> error pages today.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3779) Body Factory: support per hosts error pages.

[ASF subversion and git services (JIRA)]

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

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

Commit 1ee3c26c19c3952c6249e0ce57e57c444cd07064 in trafficserver's branch 
refs/heads/master from [~zhangzizhong]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1ee3c26 ]

TS-3779: Body Factory: support per host error pages: TESTS


> Body Factory: support per hosts error pages.
> 
>
> Key: TS-3779
> URL: https://issues.apache.org/jira/browse/TS-3779
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Core
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>  Labels: review
> Fix For: 6.0.0
>
>
> Body Factory should support per-host error pages as it supports per-language 
> error pages today.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3792) Pointing proxy.config.dns.resolv_conf at an empty (or nonexistant) file causes segmentation faults on first DNS query

[Brian Geffon (JIRA)]

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

Brian Geffon commented on TS-3792:
--

[~zhangzizhong], will take a look.

> Pointing proxy.config.dns.resolv_conf at an empty (or nonexistant) file 
> causes segmentation faults on first DNS query
> -
>
> Key: TS-3792
> URL: https://issues.apache.org/jira/browse/TS-3792
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Brian Geffon
>
> {code}
> [connect] ERROR (main_socket_fd 9): Connection refused
> [Jul 22 17:04:34.553] {0x2b293f16b960} ERROR: wrote crash log to 
> /var/log/trafficserver/crash-2015-07-22-170434.log
> traffic_server: Floating point exception (Integer divide by zero 
> [0x6d8e5a])traffic_server - STACK TRACE: 
> traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50994e]
> /lib64/libpthread.so.0[0x340d40f710]
> traffic_server[0x6d8e5a]
> traffic_server(_ZN8DNSEntry9mainEventEiP5Event+0x3d3)[0x6d9a95]
> traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50c838]
> traffic_server(_ZN12DNSProcessor5getbyEPKciiP12ContinuationRKNS_7OptionsE+0x1c1)[0x6d9e45]
> traffic_server(_ZN12DNSProcessor13gethostbynameEP12ContinuationPKcRKNS_7OptionsE+0x44)[0x6ccb30]
> traffic_server(_ZN18HostDBContinuation6do_dnsEv+0x290)[0x6cadbc]
> traffic_server(_ZN18HostDBContinuation10probeEventEiP5Event+0x2bc)[0x6ca8a6]
> traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50c838]
> traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x786d56]
> traffic_server(_ZN7EThread7executeEv+0xa0)[0x786f24]
> traffic_server(main+0x1246)[0x53da75]
> /lib64/libc.so.6(__libc_start_main+0xfd)[0x340cc1ed5d]
> traffic_server[0x4f47a9]
> Floating point exception (core dumped)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Jenkins build became unstable: tsqa-lint #340

[jenkins]

See 

[jira] [Assigned] (TS-3792) Pointing proxy.config.dns.resolv_conf at an empty (or nonexistant) file causes segmentation faults on first DNS query

[Brian Geffon (JIRA)]

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

Brian Geffon reassigned TS-3792:


Assignee: Brian Geffon

> Pointing proxy.config.dns.resolv_conf at an empty (or nonexistant) file 
> causes segmentation faults on first DNS query
> -
>
> Key: TS-3792
> URL: https://issues.apache.org/jira/browse/TS-3792
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>Assignee: Brian Geffon
>
> {code}
> [connect] ERROR (main_socket_fd 9): Connection refused
> [Jul 22 17:04:34.553] {0x2b293f16b960} ERROR: wrote crash log to 
> /var/log/trafficserver/crash-2015-07-22-170434.log
> traffic_server: Floating point exception (Integer divide by zero 
> [0x6d8e5a])traffic_server - STACK TRACE: 
> traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50994e]
> /lib64/libpthread.so.0[0x340d40f710]
> traffic_server[0x6d8e5a]
> traffic_server(_ZN8DNSEntry9mainEventEiP5Event+0x3d3)[0x6d9a95]
> traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50c838]
> traffic_server(_ZN12DNSProcessor5getbyEPKciiP12ContinuationRKNS_7OptionsE+0x1c1)[0x6d9e45]
> traffic_server(_ZN12DNSProcessor13gethostbynameEP12ContinuationPKcRKNS_7OptionsE+0x44)[0x6ccb30]
> traffic_server(_ZN18HostDBContinuation6do_dnsEv+0x290)[0x6cadbc]
> traffic_server(_ZN18HostDBContinuation10probeEventEiP5Event+0x2bc)[0x6ca8a6]
> traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50c838]
> traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x786d56]
> traffic_server(_ZN7EThread7executeEv+0xa0)[0x786f24]
> traffic_server(main+0x1246)[0x53da75]
> /lib64/libc.so.6(__libc_start_main+0xfd)[0x340cc1ed5d]
> traffic_server[0x4f47a9]
> Floating point exception (core dumped)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Build failed in Jenkins: clang-format #51

[jenkins]

See 

Changes:

[zizhang] TS-3780: Logs_xml: add logging field for incoming (interface) ip.

[zizhang] TS-3780: Logs_xml: add logging field for incoming (interface) ip. 
TESTS

[zizhang] TS-3780: Logs_xml: add logging field for incoming (interface) ip. 
DOCUMENTATION

--
[...truncated 4285 lines...]
+ echo src/proxy/http2/Http2SessionAccept.h
src/proxy/http2/Http2SessionAccept.h
+ clang-format -i src/proxy/http2/Http2SessionAccept.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HuffmanCodec.h
src/proxy/http2/HuffmanCodec.h
+ clang-format -i src/proxy/http2/HuffmanCodec.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2ConnectionState.cc
src/proxy/http2/Http2ConnectionState.cc
+ clang-format -i src/proxy/http2/Http2ConnectionState.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HTTP2.cc
src/proxy/http2/HTTP2.cc
+ clang-format -i src/proxy/http2/HTTP2.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2ClientSession.h
src/proxy/http2/Http2ClientSession.h
+ clang-format -i src/proxy/http2/Http2ClientSession.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HPACK.h
src/proxy/http2/HPACK.h
+ clang-format -i src/proxy/http2/HPACK.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HTTP2.h
src/proxy/http2/HTTP2.h
+ clang-format -i src/proxy/http2/HTTP2.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HuffmanCodec.cc
src/proxy/http2/HuffmanCodec.cc
+ clang-format -i src/proxy/http2/HuffmanCodec.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2SessionAccept.cc
src/proxy/http2/Http2SessionAccept.cc
+ clang-format -i src/proxy/http2/Http2SessionAccept.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HPACK.cc
src/proxy/http2/HPACK.cc
+ clang-format -i src/proxy/http2/HPACK.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/Main.cc
src/proxy/Main.cc
+ clang-format -i src/proxy/Main.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/UDPAPIClientTest.cc
src/proxy/UDPAPIClientTest.cc
+ clang-format -i src/proxy/UDPAPIClientTest.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/Plugin.cc
src/proxy/Plugin.cc
+ clang-format -i src/proxy/Plugin.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/TestClock.cc
src/proxy/TestClock.cc
+ clang-format -i src/proxy/TestClock.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/UDPAPIClientTest.h
src/proxy/UDPAPIClientTest.h
+ clang-format -i src/proxy/UDPAPIClientTest.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/ICPProcessor.h
src/proxy/ICPProcessor.h
+ clang-format -i src/proxy/ICPProcessor.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/InkAPITest.cc
src/proxy/InkAPITest.cc
+ clang-format -i src/proxy/InkAPITest.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/EventName.cc
src/proxy/EventName.cc
+ clang-format -i src/proxy/EventName.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/CompletionUtil.h
src/proxy/CompletionUtil.h
+ clang-format -i src/proxy/CompletionUtil.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/ReverseProxy.h
src/proxy/ReverseProxy.h
+ clang-format -i src/proxy/ReverseProxy.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/Prefetch.cc
src/proxy/Prefetch.cc
+ clang-format -i src/proxy/Prefetch.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/TestPreProc.h
src/proxy/TestPreProc.h
+ clang-format -i src/proxy/TestPreProc.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/InkPool_r.h
src/proxy/InkPool_r.h
+ clang-format -i src/proxy/InkPool_r.h
+ for f i

[jira] [Commented] (TS-3780) Logs_xml: add logging field for incoming (interface) ip.

[ASF subversion and git services (JIRA)]

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

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

Commit 727f6caafb7d492e13c8d6360b958c67256a9dca in trafficserver's branch 
refs/heads/master from [~zhangzizhong]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=727f6ca ]

TS-3780: Logs_xml: add logging field for incoming (interface) ip. DOCUMENTATION


> Logs_xml: add logging field for incoming (interface) ip.
> 
>
> Key: TS-3780
> URL: https://issues.apache.org/jira/browse/TS-3780
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Core, Logging
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>  Labels: review
> Fix For: 6.1.0
>
>
> It would be great if in a logs_xml config we could have it log the incoming 
> (interface) ip.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3780) Logs_xml: add logging field for incoming (interface) ip.

[ASF subversion and git services (JIRA)]

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

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

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

TS-3780: Logs_xml: add logging field for incoming (interface) ip. TESTS


> Logs_xml: add logging field for incoming (interface) ip.
> 
>
> Key: TS-3780
> URL: https://issues.apache.org/jira/browse/TS-3780
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Core, Logging
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>  Labels: review
> Fix For: 6.1.0
>
>
> It would be great if in a logs_xml config we could have it log the incoming 
> (interface) ip.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (TS-2152) Create a tag that logs the destination IP of the client connection

[Brian Geffon (JIRA)]

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

Brian Geffon closed TS-2152.

Resolution: Duplicate

> Create a tag that logs the destination IP of the client connection
> --
>
> Key: TS-2152
> URL: https://issues.apache.org/jira/browse/TS-2152
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Logging
>Reporter: Leif Hedstrom
>Assignee: Eric Schwartz
>  Labels: newbie
> Fix For: 6.1.0
>
>
> This would log the IP of the proxy server, as the client connected to. This 
> is useful for two reasons:
> 1) A box can be multi-homed
> 2) In a IPv4 / IPv6, you can then tell which endpoint the client connected to.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3780) Logs_xml: add logging field for incoming (interface) ip.

[ASF subversion and git services (JIRA)]

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

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

Commit 063cb576a753d75dc43f55b0a8438b59e90cc08b in trafficserver's branch 
refs/heads/master from [~zhangzizhong]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=063cb57 ]

TS-3780: Logs_xml: add logging field for incoming (interface) ip.


> Logs_xml: add logging field for incoming (interface) ip.
> 
>
> Key: TS-3780
> URL: https://issues.apache.org/jira/browse/TS-3780
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Core, Logging
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>  Labels: review
> Fix For: 6.1.0
>
>
> It would be great if in a logs_xml config we could have it log the incoming 
> (interface) ip.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3780) Logs_xml: add logging field for incoming (interface) ip.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3780:


Github user asfgit closed the pull request at:

https://github.com/apache/trafficserver/pull/258


> Logs_xml: add logging field for incoming (interface) ip.
> 
>
> Key: TS-3780
> URL: https://issues.apache.org/jira/browse/TS-3780
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Core, Logging
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>  Labels: review
> Fix For: 6.1.0
>
>
> It would be great if in a logs_xml config we could have it log the incoming 
> (interface) ip.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3774) Bug in HostDB hosts file implementation

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3774:


Github user jacksontj commented on the pull request:

https://github.com/apache/trafficserver/pull/260#issuecomment-123926596
  
LGTM


> Bug in HostDB hosts file implementation
> ---
>
> Key: TS-3774
> URL: https://issues.apache.org/jira/browse/TS-3774
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Brian Geffon
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
> Attachments: ts-3774.patch
>
>
> There is a bug in the current implementation of hostdb's use of hostsfiles. 
> Because it uses a static local variable the storage is shared and ultimately 
> will lead to race conditions if the hosts file is reloaded.
> {code}
> if (find_result != current_host_file_map->hosts_file_map.end()) {
> // TODO: Something to make this not local :/
> static HostDBInfo r;
> r.round_robin = false;
> r.round_robin_elt = false;
> r.reverse_dns = false;
> r.is_srv = false;
> ats_ip_set(r.ip(), (*find_result).second);
> return &r;
>   }
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3792) Pointing proxy.config.dns.resolv_conf at an empty (or nonexistant) file causes segmentation faults on first DNS query

[Thomas Jackson (JIRA)]

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

Thomas Jackson commented on TS-3792:


Test case to repro the issue: https://github.com/apache/trafficserver/pull/261

> Pointing proxy.config.dns.resolv_conf at an empty (or nonexistant) file 
> causes segmentation faults on first DNS query
> -
>
> Key: TS-3792
> URL: https://issues.apache.org/jira/browse/TS-3792
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>
> {code}
> [connect] ERROR (main_socket_fd 9): Connection refused
> [Jul 22 17:04:34.553] {0x2b293f16b960} ERROR: wrote crash log to 
> /var/log/trafficserver/crash-2015-07-22-170434.log
> traffic_server: Floating point exception (Integer divide by zero 
> [0x6d8e5a])traffic_server - STACK TRACE: 
> traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50994e]
> /lib64/libpthread.so.0[0x340d40f710]
> traffic_server[0x6d8e5a]
> traffic_server(_ZN8DNSEntry9mainEventEiP5Event+0x3d3)[0x6d9a95]
> traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50c838]
> traffic_server(_ZN12DNSProcessor5getbyEPKciiP12ContinuationRKNS_7OptionsE+0x1c1)[0x6d9e45]
> traffic_server(_ZN12DNSProcessor13gethostbynameEP12ContinuationPKcRKNS_7OptionsE+0x44)[0x6ccb30]
> traffic_server(_ZN18HostDBContinuation6do_dnsEv+0x290)[0x6cadbc]
> traffic_server(_ZN18HostDBContinuation10probeEventEiP5Event+0x2bc)[0x6ca8a6]
> traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50c838]
> traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x786d56]
> traffic_server(_ZN7EThread7executeEv+0xa0)[0x786f24]
> traffic_server(main+0x1246)[0x53da75]
> /lib64/libc.so.6(__libc_start_main+0xfd)[0x340cc1ed5d]
> traffic_server[0x4f47a9]
> Floating point exception (core dumped)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3792) Pointing proxy.config.dns.resolv_conf at an empty (or nonexistant) file causes segmentation faults on first DNS query

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3792:


GitHub user jacksontj opened a pull request:

https://github.com/apache/trafficserver/pull/261

Test for empty resolv_conf

Test case for TS-3792

You can merge this pull request into a Git repository by running:

$ git pull https://github.com/jacksontj/trafficserver master

Alternatively you can review and apply these changes as the patch at:

https://github.com/apache/trafficserver/pull/261.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

This closes #261


commit f886e1979df02c4ba3d1b4a9bb4332d0f6095cd4
Author: Thomas Jackson 
Date:   2015-07-23T00:35:32Z

Test for empty resolv_conf




> Pointing proxy.config.dns.resolv_conf at an empty (or nonexistant) file 
> causes segmentation faults on first DNS query
> -
>
> Key: TS-3792
> URL: https://issues.apache.org/jira/browse/TS-3792
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Thomas Jackson
>
> {code}
> [connect] ERROR (main_socket_fd 9): Connection refused
> [Jul 22 17:04:34.553] {0x2b293f16b960} ERROR: wrote crash log to 
> /var/log/trafficserver/crash-2015-07-22-170434.log
> traffic_server: Floating point exception (Integer divide by zero 
> [0x6d8e5a])traffic_server - STACK TRACE: 
> traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50994e]
> /lib64/libpthread.so.0[0x340d40f710]
> traffic_server[0x6d8e5a]
> traffic_server(_ZN8DNSEntry9mainEventEiP5Event+0x3d3)[0x6d9a95]
> traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50c838]
> traffic_server(_ZN12DNSProcessor5getbyEPKciiP12ContinuationRKNS_7OptionsE+0x1c1)[0x6d9e45]
> traffic_server(_ZN12DNSProcessor13gethostbynameEP12ContinuationPKcRKNS_7OptionsE+0x44)[0x6ccb30]
> traffic_server(_ZN18HostDBContinuation6do_dnsEv+0x290)[0x6cadbc]
> traffic_server(_ZN18HostDBContinuation10probeEventEiP5Event+0x2bc)[0x6ca8a6]
> traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50c838]
> traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x786d56]
> traffic_server(_ZN7EThread7executeEv+0xa0)[0x786f24]
> traffic_server(main+0x1246)[0x53da75]
> /lib64/libc.so.6(__libc_start_main+0xfd)[0x340cc1ed5d]
> traffic_server[0x4f47a9]
> Floating point exception (core dumped)
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-3792) Pointing proxy.config.dns.resolv_conf at an empty (or nonexistant) file causes segmentation faults on first DNS query

[Thomas Jackson (JIRA)]

Thomas Jackson created TS-3792:
--

 Summary: Pointing proxy.config.dns.resolv_conf at an empty (or 
nonexistant) file causes segmentation faults on first DNS query
 Key: TS-3792
 URL: https://issues.apache.org/jira/browse/TS-3792
 Project: Traffic Server
  Issue Type: Bug
Reporter: Thomas Jackson


{code}
[connect] ERROR (main_socket_fd 9): Connection refused
[Jul 22 17:04:34.553] {0x2b293f16b960} ERROR: wrote crash log to 
/var/log/trafficserver/crash-2015-07-22-170434.log
traffic_server: Floating point exception (Integer divide by zero 
[0x6d8e5a])traffic_server - STACK TRACE: 
traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0xc3)[0x50994e]
/lib64/libpthread.so.0[0x340d40f710]
traffic_server[0x6d8e5a]
traffic_server(_ZN8DNSEntry9mainEventEiP5Event+0x3d3)[0x6d9a95]
traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50c838]
traffic_server(_ZN12DNSProcessor5getbyEPKciiP12ContinuationRKNS_7OptionsE+0x1c1)[0x6d9e45]
traffic_server(_ZN12DNSProcessor13gethostbynameEP12ContinuationPKcRKNS_7OptionsE+0x44)[0x6ccb30]
traffic_server(_ZN18HostDBContinuation6do_dnsEv+0x290)[0x6cadbc]
traffic_server(_ZN18HostDBContinuation10probeEventEiP5Event+0x2bc)[0x6ca8a6]
traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x50c838]
traffic_server(_ZN7EThread13process_eventEP5Eventi+0xc6)[0x786d56]
traffic_server(_ZN7EThread7executeEv+0xa0)[0x786f24]
traffic_server(main+0x1246)[0x53da75]
/lib64/libc.so.6(__libc_start_main+0xfd)[0x340cc1ed5d]
traffic_server[0x4f47a9]

Floating point exception (core dumped)
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (TS-3654) ASAN heap-use-after-free in cache-hosting (regression)

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs resolved TS-3654.

Resolution: Fixed

> ASAN heap-use-after-free in cache-hosting (regression)
> --
>
> Key: TS-3654
> URL: https://issues.apache.org/jira/browse/TS-3654
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 6.1.0
>
>
> {code}
> RPRINT Cache_vol: 1 128 Megabyte Volumes
> RPRINT Cache_vol: Not enough space for 10 volume
> RPRINT Cache_vol: Random Volumes after clearing the disks
> RPRINT Cache_vol: volume=1 scheme=http size=128
> RPRINT Cache_vol: Random Volumes without clearing the disks
> RPRINT Cache_vol: volume=1 scheme=rtsp size=128
> =
> ==3733==ERROR: AddressSanitizer: heap-use-after-free on address 
> 0x604a2960 at pc 0xa7ce83 bp 0x7f3c7f946980 sp 0x7f3c7f946970
> READ of size 8 at 0x604a2960 thread T3 ([ET_NET 2])
> #0 0xa7ce82 in cplist_update ../../../../iocore/cache/Cache.cc:3230
> #1 0xa7ce82 in cplist_reconfigure() ../../../../iocore/cache/Cache.cc:3374
> #2 0xac619e in execute_and_verify(RegressionTest*) 
> ../../../../iocore/cache/CacheHosting.cc:994
> #3 0xac75f8 in RegressionTest_Cache_vol(RegressionTest*, int, int*) 
> ../../../../iocore/cache/CacheHosting.cc:840
> #4 0x7f3c8480b4d2 in start_test ../../../../lib/ts/Regression.cc:77
> #5 0x7f3c8480b4d2 in RegressionTest::run_some() 
> ../../../../lib/ts/Regression.cc:125
> #6 0x7f3c8480b9b6 in RegressionTest::check_status() 
> ../../../../lib/ts/Regression.cc:140
> #7 0x57b5b4 in RegressionCont::mainEvent(int, Event*) 
> ../../../proxy/Main.cc:1220
> #8 0xc8b86e in Continuation::handleEvent(int, void*) 
> ../../../../iocore/eventsystem/I_Continuation.h:145
> #9 0xc8b86e in EThread::process_event(Event*, int) 
> ../../../../iocore/eventsystem/UnixEThread.cc:128
> #10 0xc8da67 in EThread::execute() 
> ../../../../iocore/eventsystem/UnixEThread.cc:207
> #11 0xc8a488 in spawn_thread_internal 
> ../../../../iocore/eventsystem/Thread.cc:85
> #12 0x7f3c84392529 in start_thread (/lib64/libpthread.so.0+0x3813e07529)
> #13 0x381370022c in __clone (/lib64/libc.so.6+0x381370022c)
> 0x604a2960 is located 16 bytes inside of 40-byte region 
> [0x604a2950,0x604a2978)
> freed by thread T3 ([ET_NET 2]) here:
> #0 0x7f3c84aaf64f in operator delete(void*) (/lib64/libasan.so.1+0x5864f)
> #1 0xabbd16 in CacheDisk::delete_volume(int) 
> ../../../../iocore/cache/CacheDisk.cc:330
> #2 0xa7bfe0 in cplist_update ../../../../iocore/cache/Cache.cc:3212
> #3 0xa7bfe0 in cplist_reconfigure() ../../../../iocore/cache/Cache.cc:3374
> #4 0xac619e in execute_and_verify(RegressionTest*) 
> ../../../../iocore/cache/CacheHosting.cc:994
> #5 0xac75f8 in RegressionTest_Cache_vol(RegressionTest*, int, int*) 
> ../../../../iocore/cache/CacheHosting.cc:840
> #6 0x7f3c8480b4d2 in start_test ../../../../lib/ts/Regression.cc:77
> #7 0x7f3c8480b4d2 in RegressionTest::run_some() 
> ../../../../lib/ts/Regression.cc:125
> #8 0x7f3c8480b9b6 in RegressionTest::check_status() 
> ../../../../lib/ts/Regression.cc:140
> #9 0x57b5b4 in RegressionCont::mainEvent(int, Event*) 
> ../../../proxy/Main.cc:1220
> #10 0xc8b86e in Continuation::handleEvent(int, void*) 
> ../../../../iocore/eventsystem/I_Continuation.h:145
> #11 0xc8b86e in EThread::process_event(Event*, int) 
> ../../../../iocore/eventsystem/UnixEThread.cc:128
> #12 0xc8da67 in EThread::execute() 
> ../../../../iocore/eventsystem/UnixEThread.cc:207
> #13 0xc8a488 in spawn_thread_internal 
> ../../../../iocore/eventsystem/Thread.cc:85
> #14 0x7f3c84392529 in start_thread (/lib64/libpthread.so.0+0x3813e07529)
> previously allocated by thread T3 ([ET_NET 2]) here:
> #0 0x7f3c84aaf14f in operator new(unsigned long) 
> (/lib64/libasan.so.1+0x5814f)
> #1 0xaba5ca in CacheDisk::create_volume(int, long, int) 
> ../../../../iocore/cache/CacheDisk.cc:296
> #2 0xa74f81 in create_volume ../../../../iocore/cache/Cache.cc:3551
> #3 0xa7ca20 in cplist_reconfigure() ../../../../iocore/cache/Cache.cc:3405
> #4 0xac619e in execute_and_verify(RegressionTest*) 
> ../../../../iocore/cache/CacheHosting.cc:994
> #5 0xac75f8 in RegressionTest_Cache_vol(RegressionTest*, int, int*) 
> ../../../../iocore/cache/CacheHosting.cc:840
> #6 0x7f3c8480b4d2 in start_test ../../../../lib/ts/Regression.cc:77
> #7 0x7f3c8480b4d2 in RegressionTest::run_some() 
> ../../../../lib/ts/Regression.cc:125
> #8 0x7f3c8480b9b6 in RegressionTest::check_status() 
> ../../../../lib/ts/Regression.cc:140
> #9 0x57b5b4 in RegressionCont::mai

Build failed in Jenkins: tsqa-master #718

[jenkins]

See 

Changes:

[shinrich] TS-3654: ASAN heap-use-after-free in cache-hosting (regression).

--
[...truncated 506 lines...]
INFO 2015-07-22 21:13:49,590 - sending data back to the client
INFO 2015-07-22 21:13:51,992 - sending data back to the client
INFO 2015-07-22 21:13:54,396 - sending data back to the client
INFO 2015-07-22 21:13:58,401 - sending data back to the client
ok
test_chunked_keepalive_server (test_chunked.TestChunked) ... INFO 2015-07-22 
21:14:02,406 - sending data back to the client
INFO 2015-07-22 21:14:05,412 - sending data back to the client
ok
Test that the origin does in fact support keepalive ... INFO 2015-07-22 
21:14:06,419 - sending data back to the client
INFO 2015-07-22 21:14:09,423 - sending data back to the client
INFO 2015-07-22 21:14:10,426 - sending data back to the client
INFO 2015-07-22 21:14:12,427 - Client disconnected
INFO 2015-07-22 21:14:12,829 - sending data back to the client
INFO 2015-07-22 21:14:13,231 - sending data back to the client
INFO 2015-07-22 21:14:15,232 - Client disconnected
INFO 2015-07-22 21:14:17,236 - sending data back to the client
ok
INFO 2015-07-22 21:14:19,246 - Client disconnected
INFO 2015-07-22 21:14:19,438 - Environment prefix is /tmp/tsqa.env.Xw97no
INFO 2015-07-22 21:14:21,240 - Client disconnected
Verify that we get 502s from an origin which just did a bind ... ok
Verify that we get 200s from origins that delayed_accept_after_connect ... ok
Verify that we get 504s from origins that die_on_connect ... ok
Verify that we get 502s from origins that bind + listen ... ok
Verify that we get 504s from origins that return a partial_response ... FAIL
Verify that we get 200s from origins that reset_after_accept ... FAIL
INFO 2015-07-22 21:14:30,738 - Environment prefix is /tmp/tsqa.env.eT9Cta
test_default_404 (test_example.TestBootstrap) ... ok
Test that traffic_line works, and verify that the values for proxy.config ... ok
INFO 2015-07-22 21:15:00,385 - Starting build 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-07-22 21:15:54,060 - Build completed 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-07-22 21:15:54,126 - Environment prefix is /tmp/tsqa.env.CgFgWt
test_spdy (test_example.TestConfigureFlags) ... ok
INFO 2015-07-22 21:15:57,539 - Environment prefix is /tmp/tsqa.env.SnAee7
test_basic_proxy (test_example.TestDynamicHTTPEndpointCase) ... 127.0.0.1 - - 
[22/Jul/2015 21:16:00] "GET /test HTTP/1.1" 404 0
ok
INFO 2015-07-22 21:16:00,947 - Environment prefix is /tmp/tsqa.env.dV1P_e
test_logs_exist (test_example.TestLogRefCounting) ... 127.0.0.1 - - 
[22/Jul/2015 21:16:04] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 21:16:04] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 21:16:04] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 21:16:04] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 21:16:04] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 21:16:04] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 21:16:04] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 21:16:04] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 21:16:04] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 21:16:04] "GET / HTTP/1.1" 404 0
FAIL
INFO 2015-07-22 21:16:14,451 - Environment prefix is /tmp/tsqa.env.Yk_G5a
test_logs_exist (test_example.TestLogs) ... FAIL
SKIP: Skip the entire class
INFO 2015-07-22 21:16:27,903 - Environment prefix is /tmp/tsqa.env.llflTu
test_basic_intercept (test_example.TestServerIntercept) ... 127.0.0.1 - - 
[22/Jul/2015 21:16:31] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 21:16:31] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 21:16:31] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 21:16:31] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 21:16:31] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 21:16:31] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 21:16:31] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 21:16:31] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 21:16:31] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 21:16:31] "GET / HTTP/1.1" 200 5
ok
INFO 2015-07-22 21:16:31,343 - Environment prefix is /tmp/tsqa.env.zJ8lJh
test_lookup_timeout (test_hostdb.TestHostDBFailedDNS) ... ok
INFO 2015-07-22 21:16:36,774 - Environment prefix is /tmp/tsqa.env.17OC6b
Test basic fnctionality of hosts files ... ok
Test that changes to hosts file get loaded within host_file.interval ... ok
INFO 2015-07-22 21:16:46,249 - Environment prefix is /tmp/tsqa.env.xhPDpR
SKIP: 
 >> begin captured logging << ---

[jira] [Updated] (TS-3791) Diagnostics can crash in PCRE JIT when there's a bad config

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3791:
--
Fix Version/s: 6.1.0

> Diagnostics can crash in PCRE JIT when there's a bad config 
> 
>
> Key: TS-3791
> URL: https://issues.apache.org/jira/browse/TS-3791
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>  Labels: crash
> Fix For: 6.1.0
>
>
> Somewhat strange setup, but basically with a bad parent.config entry, e.g.
> {code}
> dest_domain=. parent="foo.example.com"
> {code}
> (notice the missing :port), and I run traffic_server with a -T option, e.g.
> {code}
> ./bin/traffic_server -T parent
> {code}
> I get a crash with a core of
> {code}
> (gdb) bt
> #0  0x752019c8 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:55
> #1  0x7520365a in __GI_abort () at abort.c:89
> #2  0x77bc3fb8 in ink_die_die_die () at 
> ../../../../lib/ts/ink_error.cc:43
> #3  ink_fatal_va (fmt=0x77bd0820 "ats_malloc: couldn't allocate %zu 
> bytes", ap=ap@entry=0x73994808) at ../../../../lib/ts/ink_error.cc:65
> #4  0x77bc404c in ink_fatal 
> (message_format=message_format@entry=0x77bd0820 "ats_malloc: couldn't 
> allocate %zu bytes") at ../../../../lib/ts/ink_error.cc:73
> #5  0x77bc6f16 in ats_malloc (size=32) at 
> ../../../../lib/ts/ink_memory.cc:56
> #6  0x76911694 in sljit_allocate_stack (allocator_data=0x0, 
> max_limit=1048576, limit=8192) at sljit/sljitUtils.c:236
> #7  pcre_jit_stack_alloc (startsize=8192, maxsize=, 
> maxsize@entry=1048576) at pcre_jit_compile.c:10571
> #8  0x77bbc656 in get_jit_stack (data=) at 
> ../../../../lib/ts/Regex.cc:44
> #9  0x76911358 in _pcre_jit_exec 
> (extra_data=extra_data@entry=0x10aa2d0, subject=subject@entry=0x80ac67 
> "pmgmt", length=length@entry=5, start_offset=start_offset@entry=0, 
> options=options@entry=0, offsets=offsets@entry=0x73994be0, 
> offset_count=2) at pcre_jit_compile.c:10420
> #10 0x768e9e7e in pcre_exec (argument_re=0x10aa270, 
> extra_data=, subject=subject@entry=0x80ac67 "pmgmt", 
> length=length@entry=5, start_offset=start_offset@entry=0, 
> options=options@entry=0, offsets=0x73994be0, offsetcount=30) at 
> pcre_exec.c:6483
> #11 0x77bbc79e in Regex::exec (this=, 
> str=str@entry=0x80ac67 "pmgmt", length=length@entry=5, 
> ovector=ovector@entry=0x73994be0, ovecsize=ovecsize@entry=30) at 
> ../../../../lib/ts/Regex.cc:120
> #12 0x77bbc7c5 in Regex::exec (this=, 
> str=str@entry=0x80ac67 "pmgmt", length=length@entry=5) at 
> ../../../../lib/ts/Regex.cc:112
> #13 0x77bbca1f in DFA::match (this=, 
> str=str@entry=0x80ac67 "pmgmt", length=5) at ../../../../lib/ts/Regex.cc:235
> #14 0x77bbca67 in DFA::match (this=, 
> str=str@entry=0x80ac67 "pmgmt") at ../../../../lib/ts/Regex.cc:225
> #15 0x77bb0a32 in Diags::tag_activated (this=this@entry=0x10aa140, 
> tag=tag@entry=0x80ac67 "pmgmt", mode=mode@entry=DiagsTagType_Debug) at 
> ../../../../lib/ts/Diags.cc:394
> #16 0x77bb1429 in on (mode=DiagsTagType_Debug, tag=0x80ac67 "pmgmt", 
> this=0x10aa140) at ../../../../lib/ts/Diags.h:171
> #17 Diags::log (this=0x10aa140, tag=tag@entry=0x80ac67 "pmgmt", 
> level=level@entry=DL_Debug, file=file@entry=0x80a850 
> "../../../mgmt/ProcessManager.cc", func=func@entry=0x80acf0 
>  "processSignalQueue", 
> line=line@entry=148, format_string=0x80a8f8 "[ProcessManager] ==> Signalling 
> local manager '%d'\n") at ../../../../lib/ts/Diags.cc:513
> #18 0x006979f5 in ProcessManager::processSignalQueue (this=0x10eab30) 
> at ../../../mgmt/ProcessManager.cc:148
> #19 0x00697ffd in startProcessManager (arg=) at 
> ../../../mgmt/ProcessManager.cc:63
> #20 0x76039555 in start_thread (arg=0x73995700) at 
> pthread_create.c:333
> #21 0x752cfb9d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3791) Diagnostics can crash in PCRE JIT when there's a bad config

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3791:
--
Labels: crash  (was: )

> Diagnostics can crash in PCRE JIT when there's a bad config 
> 
>
> Key: TS-3791
> URL: https://issues.apache.org/jira/browse/TS-3791
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
>  Labels: crash
> Fix For: 6.1.0
>
>
> Somewhat strange setup, but basically with a bad parent.config entry, e.g.
> {code}
> dest_domain=. parent="foo.example.com"
> {code}
> (notice the missing :port), and I run traffic_server with a -T option, e.g.
> {code}
> ./bin/traffic_server -T parent
> {code}
> I get a crash with a core of
> {code}
> (gdb) bt
> #0  0x752019c8 in __GI_raise (sig=sig@entry=6) at 
> ../sysdeps/unix/sysv/linux/raise.c:55
> #1  0x7520365a in __GI_abort () at abort.c:89
> #2  0x77bc3fb8 in ink_die_die_die () at 
> ../../../../lib/ts/ink_error.cc:43
> #3  ink_fatal_va (fmt=0x77bd0820 "ats_malloc: couldn't allocate %zu 
> bytes", ap=ap@entry=0x73994808) at ../../../../lib/ts/ink_error.cc:65
> #4  0x77bc404c in ink_fatal 
> (message_format=message_format@entry=0x77bd0820 "ats_malloc: couldn't 
> allocate %zu bytes") at ../../../../lib/ts/ink_error.cc:73
> #5  0x77bc6f16 in ats_malloc (size=32) at 
> ../../../../lib/ts/ink_memory.cc:56
> #6  0x76911694 in sljit_allocate_stack (allocator_data=0x0, 
> max_limit=1048576, limit=8192) at sljit/sljitUtils.c:236
> #7  pcre_jit_stack_alloc (startsize=8192, maxsize=, 
> maxsize@entry=1048576) at pcre_jit_compile.c:10571
> #8  0x77bbc656 in get_jit_stack (data=) at 
> ../../../../lib/ts/Regex.cc:44
> #9  0x76911358 in _pcre_jit_exec 
> (extra_data=extra_data@entry=0x10aa2d0, subject=subject@entry=0x80ac67 
> "pmgmt", length=length@entry=5, start_offset=start_offset@entry=0, 
> options=options@entry=0, offsets=offsets@entry=0x73994be0, 
> offset_count=2) at pcre_jit_compile.c:10420
> #10 0x768e9e7e in pcre_exec (argument_re=0x10aa270, 
> extra_data=, subject=subject@entry=0x80ac67 "pmgmt", 
> length=length@entry=5, start_offset=start_offset@entry=0, 
> options=options@entry=0, offsets=0x73994be0, offsetcount=30) at 
> pcre_exec.c:6483
> #11 0x77bbc79e in Regex::exec (this=, 
> str=str@entry=0x80ac67 "pmgmt", length=length@entry=5, 
> ovector=ovector@entry=0x73994be0, ovecsize=ovecsize@entry=30) at 
> ../../../../lib/ts/Regex.cc:120
> #12 0x77bbc7c5 in Regex::exec (this=, 
> str=str@entry=0x80ac67 "pmgmt", length=length@entry=5) at 
> ../../../../lib/ts/Regex.cc:112
> #13 0x77bbca1f in DFA::match (this=, 
> str=str@entry=0x80ac67 "pmgmt", length=5) at ../../../../lib/ts/Regex.cc:235
> #14 0x77bbca67 in DFA::match (this=, 
> str=str@entry=0x80ac67 "pmgmt") at ../../../../lib/ts/Regex.cc:225
> #15 0x77bb0a32 in Diags::tag_activated (this=this@entry=0x10aa140, 
> tag=tag@entry=0x80ac67 "pmgmt", mode=mode@entry=DiagsTagType_Debug) at 
> ../../../../lib/ts/Diags.cc:394
> #16 0x77bb1429 in on (mode=DiagsTagType_Debug, tag=0x80ac67 "pmgmt", 
> this=0x10aa140) at ../../../../lib/ts/Diags.h:171
> #17 Diags::log (this=0x10aa140, tag=tag@entry=0x80ac67 "pmgmt", 
> level=level@entry=DL_Debug, file=file@entry=0x80a850 
> "../../../mgmt/ProcessManager.cc", func=func@entry=0x80acf0 
>  "processSignalQueue", 
> line=line@entry=148, format_string=0x80a8f8 "[ProcessManager] ==> Signalling 
> local manager '%d'\n") at ../../../../lib/ts/Diags.cc:513
> #18 0x006979f5 in ProcessManager::processSignalQueue (this=0x10eab30) 
> at ../../../mgmt/ProcessManager.cc:148
> #19 0x00697ffd in startProcessManager (arg=) at 
> ../../../mgmt/ProcessManager.cc:63
> #20 0x76039555 in start_thread (arg=0x73995700) at 
> pthread_create.c:333
> #21 0x752cfb9d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:109
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TS-3744) Crash (Seg Fault) when reenabling a VIO from a continuator which is different from the VIO's continuator.

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll edited comment on TS-3744 at 7/22/15 9:17 PM:
--

-The transform continuation will need to track the write ready state of the 
cache VIO. In item (3) the continuation should mark that the cache VIO is in a 
write ready state-. When you get to step 4.1 you would send a READ_READY to the 
cache continuation using the same mechanism you send WRITE_READY to your 
upstream. That is, you send WRITE_READY upstream when you can receive data and 
send READ_READY downstream when you make data available to be read.

Keeping all the data in memory being a problem depends on how fast the slower 
of your user agent and cache agent consume the data. This can be an issue in 
the real world and the flow control logic was added to ameloriate the problem 
by limiting the amount of buffer space consumed by a transaction.


was (Author: amc):
The transform continuation will need to track the write ready state of the 
cache VIO. In item (3) the continuation should mark that the cache VIO is in a 
write ready state. When you get to step 4.1 you would send a READ_READY to the 
cache continuation using the same mechanism you send WRITE_READY to your 
upstream. That is, you send WRITE_READY upstream when you can receive data and 
send READ_READY downstream when you make data available to be read.

Keeping all the data in memory being a problem depends on how fast the slower 
of your user agent and cache agent consume the data. This can be an issue in 
the real world and the flow control logic was added to ameloriate the problem 
by limiting the amount of buffer space consumed by a transaction.

> Crash (Seg Fault) when reenabling a VIO from a continuator which is different 
> from the VIO's continuator.
> -
>
> Key: TS-3744
> URL: https://issues.apache.org/jira/browse/TS-3744
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins, TS API
>Affects Versions: 5.3.0
>Reporter: Pavel Vazharov
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> Hi,
> I'm trying to create ATS plugin which uses the API for cache write 
> (TSCacheWrite, TSVConnWrite). For the write part, from a transformation, I'm 
> trying to stream the data to both the client and the cache in the same time. 
> The problem described below IMO can be summarized as - crash reenabling of 
> one VIO from a continuator which is different from the VIO's continuator.
> Here is the backtrace of the crash. 
> traffic_server: Segmentation fault (Address not mapped to object [0x28])
> traffic_server - STACK TRACE: 
> /usr/local/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ad13e]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x2b9092c2a340]
> /usr/local/bin/traffic_server(_ZN7CacheVC8reenableEP3VIO+0x28)[0x6db868]
> /home/freak82/ats/src/plugins/ccontent/ccontent.so(+0x29e5)[0x2b9096bce9e5]
> /home/freak82/ats/src/plugins/ccontent/ccontent.so(+0x3094)[0x2b9096bcf094]
> /usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x120)[0x767ea0]
> /usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x81b)[0x768aab]
> /usr/local/bin/traffic_server(main+0xee6)[0x495436]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x2b909387dec5]
> /usr/local/bin/traffic_server[0x49ba6f]
> It's like the VIO mutex->thread_holding or the VIO object itself are in some 
> inappropriate state or invalid. The VIO has the same memory address as the 
> originally created one and it's continuator is not explicitly destroyed 
> (TSContDestroy). The associated buffer and reader are also alive.
> I'm not sure if the thing (writing "in-parallel") that I'm trying to do is 
> possible with the current API, by design? Is it possible/allowed by design to 
> copy bytes to one VIO buffer and reenable the same VIO from another 
> continuator, not the same continuator as the one of the VIO.
> If it's possible am I doing something wrong or this is a bug?
> Basically, I'm trying to do it in the following way. The explanations skip 
> the error handling.
> 1. On transformation start, on the first EVENT_IMMEDIATE from the upstream, 
> the code initializes the client stream (TSBuffer, TSBufferReader and TSVIO as 
> in the null-transform plugin) and then start the cache write (TSCacheWrite) 
> with a created and digested cache key (TSCacheKey).
> 2. On EVENT_CACHE_OPEN_WRITE, the code initializes the cache stream 
> (TSBuffer, TSBufferReader and TSVIO) in the same way as the client stream, 
> but using the passed TSCont and TSVConn from the event data. So far, it works 
> as expected.
> 3. Both continuator callbacks, for the transfor

[jira] [Created] (TS-3791) Diagnostics can crash in PCRE JIT when there's a bad config

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-3791:
-

 Summary: Diagnostics can crash in PCRE JIT when there's a bad 
config 
 Key: TS-3791
 URL: https://issues.apache.org/jira/browse/TS-3791
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: Leif Hedstrom


Somewhat strange setup, but basically with a bad parent.config entry, e.g.

{code}
dest_domain=. parent="foo.example.com"
{code}

(notice the missing :port), and I run traffic_server with a -T option, e.g.

{code}
./bin/traffic_server -T parent
{code}

I get a crash with a core of

{code}
(gdb) bt
#0  0x752019c8 in __GI_raise (sig=sig@entry=6) at 
../sysdeps/unix/sysv/linux/raise.c:55
#1  0x7520365a in __GI_abort () at abort.c:89
#2  0x77bc3fb8 in ink_die_die_die () at 
../../../../lib/ts/ink_error.cc:43
#3  ink_fatal_va (fmt=0x77bd0820 "ats_malloc: couldn't allocate %zu bytes", 
ap=ap@entry=0x73994808) at ../../../../lib/ts/ink_error.cc:65
#4  0x77bc404c in ink_fatal 
(message_format=message_format@entry=0x77bd0820 "ats_malloc: couldn't 
allocate %zu bytes") at ../../../../lib/ts/ink_error.cc:73
#5  0x77bc6f16 in ats_malloc (size=32) at 
../../../../lib/ts/ink_memory.cc:56
#6  0x76911694 in sljit_allocate_stack (allocator_data=0x0, 
max_limit=1048576, limit=8192) at sljit/sljitUtils.c:236
#7  pcre_jit_stack_alloc (startsize=8192, maxsize=, 
maxsize@entry=1048576) at pcre_jit_compile.c:10571
#8  0x77bbc656 in get_jit_stack (data=) at 
../../../../lib/ts/Regex.cc:44
#9  0x76911358 in _pcre_jit_exec 
(extra_data=extra_data@entry=0x10aa2d0, subject=subject@entry=0x80ac67 "pmgmt", 
length=length@entry=5, start_offset=start_offset@entry=0, 
options=options@entry=0, offsets=offsets@entry=0x73994be0, offset_count=2) 
at pcre_jit_compile.c:10420
#10 0x768e9e7e in pcre_exec (argument_re=0x10aa270, 
extra_data=, subject=subject@entry=0x80ac67 "pmgmt", 
length=length@entry=5, start_offset=start_offset@entry=0, 
options=options@entry=0, offsets=0x73994be0, offsetcount=30) at 
pcre_exec.c:6483
#11 0x77bbc79e in Regex::exec (this=, 
str=str@entry=0x80ac67 "pmgmt", length=length@entry=5, 
ovector=ovector@entry=0x73994be0, ovecsize=ovecsize@entry=30) at 
../../../../lib/ts/Regex.cc:120
#12 0x77bbc7c5 in Regex::exec (this=, 
str=str@entry=0x80ac67 "pmgmt", length=length@entry=5) at 
../../../../lib/ts/Regex.cc:112
#13 0x77bbca1f in DFA::match (this=, 
str=str@entry=0x80ac67 "pmgmt", length=5) at ../../../../lib/ts/Regex.cc:235
#14 0x77bbca67 in DFA::match (this=, 
str=str@entry=0x80ac67 "pmgmt") at ../../../../lib/ts/Regex.cc:225
#15 0x77bb0a32 in Diags::tag_activated (this=this@entry=0x10aa140, 
tag=tag@entry=0x80ac67 "pmgmt", mode=mode@entry=DiagsTagType_Debug) at 
../../../../lib/ts/Diags.cc:394
#16 0x77bb1429 in on (mode=DiagsTagType_Debug, tag=0x80ac67 "pmgmt", 
this=0x10aa140) at ../../../../lib/ts/Diags.h:171
#17 Diags::log (this=0x10aa140, tag=tag@entry=0x80ac67 "pmgmt", 
level=level@entry=DL_Debug, file=file@entry=0x80a850 
"../../../mgmt/ProcessManager.cc", func=func@entry=0x80acf0 
 "processSignalQueue", 
line=line@entry=148, format_string=0x80a8f8 "[ProcessManager] ==> Signalling 
local manager '%d'\n") at ../../../../lib/ts/Diags.cc:513
#18 0x006979f5 in ProcessManager::processSignalQueue (this=0x10eab30) 
at ../../../mgmt/ProcessManager.cc:148
#19 0x00697ffd in startProcessManager (arg=) at 
../../../mgmt/ProcessManager.cc:63
#20 0x76039555 in start_thread (arg=0x73995700) at 
pthread_create.c:333
#21 0x752cfb9d in clone () at 
../sysdeps/unix/sysv/linux/x86_64/clone.S:109
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3744) Crash (Seg Fault) when reenabling a VIO from a continuator which is different from the VIO's continuator.

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll commented on TS-3744:
-

The transform continuation will need to track the write ready state of the 
cache VIO. In item (3) the continuation should mark that the cache VIO is in a 
write ready state. When you get to step 4.1 you would send a READ_READY to the 
cache continuation using the same mechanism you send WRITE_READY to your 
upstream. That is, you send WRITE_READY upstream when you can receive data and 
send READ_READY downstream when you make data available to be read.

Keeping all the data in memory being a problem depends on how fast the slower 
of your user agent and cache agent consume the data. This can be an issue in 
the real world and the flow control logic was added to ameloriate the problem 
by limiting the amount of buffer space consumed by a transaction.

> Crash (Seg Fault) when reenabling a VIO from a continuator which is different 
> from the VIO's continuator.
> -
>
> Key: TS-3744
> URL: https://issues.apache.org/jira/browse/TS-3744
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins, TS API
>Affects Versions: 5.3.0
>Reporter: Pavel Vazharov
> Fix For: 6.1.0
>
>
> Hi,
> I'm trying to create ATS plugin which uses the API for cache write 
> (TSCacheWrite, TSVConnWrite). For the write part, from a transformation, I'm 
> trying to stream the data to both the client and the cache in the same time. 
> The problem described below IMO can be summarized as - crash reenabling of 
> one VIO from a continuator which is different from the VIO's continuator.
> Here is the backtrace of the crash. 
> traffic_server: Segmentation fault (Address not mapped to object [0x28])
> traffic_server - STACK TRACE: 
> /usr/local/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ad13e]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x2b9092c2a340]
> /usr/local/bin/traffic_server(_ZN7CacheVC8reenableEP3VIO+0x28)[0x6db868]
> /home/freak82/ats/src/plugins/ccontent/ccontent.so(+0x29e5)[0x2b9096bce9e5]
> /home/freak82/ats/src/plugins/ccontent/ccontent.so(+0x3094)[0x2b9096bcf094]
> /usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x120)[0x767ea0]
> /usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x81b)[0x768aab]
> /usr/local/bin/traffic_server(main+0xee6)[0x495436]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x2b909387dec5]
> /usr/local/bin/traffic_server[0x49ba6f]
> It's like the VIO mutex->thread_holding or the VIO object itself are in some 
> inappropriate state or invalid. The VIO has the same memory address as the 
> originally created one and it's continuator is not explicitly destroyed 
> (TSContDestroy). The associated buffer and reader are also alive.
> I'm not sure if the thing (writing "in-parallel") that I'm trying to do is 
> possible with the current API, by design? Is it possible/allowed by design to 
> copy bytes to one VIO buffer and reenable the same VIO from another 
> continuator, not the same continuator as the one of the VIO.
> If it's possible am I doing something wrong or this is a bug?
> Basically, I'm trying to do it in the following way. The explanations skip 
> the error handling.
> 1. On transformation start, on the first EVENT_IMMEDIATE from the upstream, 
> the code initializes the client stream (TSBuffer, TSBufferReader and TSVIO as 
> in the null-transform plugin) and then start the cache write (TSCacheWrite) 
> with a created and digested cache key (TSCacheKey).
> 2. On EVENT_CACHE_OPEN_WRITE, the code initializes the cache stream 
> (TSBuffer, TSBufferReader and TSVIO) in the same way as the client stream, 
> but using the passed TSCont and TSVConn from the event data. So far, it works 
> as expected.
> 3. Both continuator callbacks, for the transformation and for the cache 
> write, are handling events WRITE_READY and WRITE_COMPLETE. The transformation 
> callback also handles EVENT_IMMEDIATE to know when there is more data from 
> the upstream.
> I was thinking to mark every stream as ready when the corresponding callback 
> receives WRITE_READY, and when both streams are ready to copy the available 
> data from the upstream to them, then reenable the both streams and the 
> upstream. Then when there are new data available from the upstream, to copy 
> them again when the both streams becomes ready, etc, etc.
> Usually the first writes/copies and reenables are made from inside the 
> TSCacheWrite, because it's reentrant and generates WRITE_READY for the cache 
> continuator. These operations succeeds. The problem is that the plugin leads 
> to crash in the ATS when it tries to reeenable the cache VIO fr

[jira] [Assigned] (TS-3744) Crash (Seg Fault) when reenabling a VIO from a continuator which is different from the VIO's continuator.

[Alan M. Carroll (JIRA)]

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

Alan M. Carroll reassigned TS-3744:
---

Assignee: Alan M. Carroll

> Crash (Seg Fault) when reenabling a VIO from a continuator which is different 
> from the VIO's continuator.
> -
>
> Key: TS-3744
> URL: https://issues.apache.org/jira/browse/TS-3744
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins, TS API
>Affects Versions: 5.3.0
>Reporter: Pavel Vazharov
>Assignee: Alan M. Carroll
> Fix For: 6.1.0
>
>
> Hi,
> I'm trying to create ATS plugin which uses the API for cache write 
> (TSCacheWrite, TSVConnWrite). For the write part, from a transformation, I'm 
> trying to stream the data to both the client and the cache in the same time. 
> The problem described below IMO can be summarized as - crash reenabling of 
> one VIO from a continuator which is different from the VIO's continuator.
> Here is the backtrace of the crash. 
> traffic_server: Segmentation fault (Address not mapped to object [0x28])
> traffic_server - STACK TRACE: 
> /usr/local/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ad13e]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x10340)[0x2b9092c2a340]
> /usr/local/bin/traffic_server(_ZN7CacheVC8reenableEP3VIO+0x28)[0x6db868]
> /home/freak82/ats/src/plugins/ccontent/ccontent.so(+0x29e5)[0x2b9096bce9e5]
> /home/freak82/ats/src/plugins/ccontent/ccontent.so(+0x3094)[0x2b9096bcf094]
> /usr/local/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x120)[0x767ea0]
> /usr/local/bin/traffic_server(_ZN7EThread7executeEv+0x81b)[0x768aab]
> /usr/local/bin/traffic_server(main+0xee6)[0x495436]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x2b909387dec5]
> /usr/local/bin/traffic_server[0x49ba6f]
> It's like the VIO mutex->thread_holding or the VIO object itself are in some 
> inappropriate state or invalid. The VIO has the same memory address as the 
> originally created one and it's continuator is not explicitly destroyed 
> (TSContDestroy). The associated buffer and reader are also alive.
> I'm not sure if the thing (writing "in-parallel") that I'm trying to do is 
> possible with the current API, by design? Is it possible/allowed by design to 
> copy bytes to one VIO buffer and reenable the same VIO from another 
> continuator, not the same continuator as the one of the VIO.
> If it's possible am I doing something wrong or this is a bug?
> Basically, I'm trying to do it in the following way. The explanations skip 
> the error handling.
> 1. On transformation start, on the first EVENT_IMMEDIATE from the upstream, 
> the code initializes the client stream (TSBuffer, TSBufferReader and TSVIO as 
> in the null-transform plugin) and then start the cache write (TSCacheWrite) 
> with a created and digested cache key (TSCacheKey).
> 2. On EVENT_CACHE_OPEN_WRITE, the code initializes the cache stream 
> (TSBuffer, TSBufferReader and TSVIO) in the same way as the client stream, 
> but using the passed TSCont and TSVConn from the event data. So far, it works 
> as expected.
> 3. Both continuator callbacks, for the transformation and for the cache 
> write, are handling events WRITE_READY and WRITE_COMPLETE. The transformation 
> callback also handles EVENT_IMMEDIATE to know when there is more data from 
> the upstream.
> I was thinking to mark every stream as ready when the corresponding callback 
> receives WRITE_READY, and when both streams are ready to copy the available 
> data from the upstream to them, then reenable the both streams and the 
> upstream. Then when there are new data available from the upstream, to copy 
> them again when the both streams becomes ready, etc, etc.
> Usually the first writes/copies and reenables are made from inside the 
> TSCacheWrite, because it's reentrant and generates WRITE_READY for the cache 
> continuator. These operations succeeds. The problem is that the plugin leads 
> to crash in the ATS when it tries to reeenable the cache VIO from inside the 
> transform continuator.
> I tried to pass whole data from the upstream to the client first, copying 
> (TSIOBufferCopy) "in-paralles" them to a temporary buffer, and initiate cache 
> write at the end of the transformation and then write the data from the 
> buffer to the cache VIO (similarly to the metalink plugin). This also works 
> as expected.
> Thanks,
> Pavel.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3775) ASAN crash while running regression test Cache_vol

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-3775:


The true commit is on the duplicate bug TS-3654

> ASAN crash while running regression test Cache_vol
> --
>
> Key: TS-3775
> URL: https://issues.apache.org/jira/browse/TS-3775
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Attachments: ts-3775.diff
>
>
> Seen while running master built with ASAN on FC 21.  I have a patch which 
> I'll attach and discuss in comment.
> {code}
> REGRESSION TEST Cache_vol started
> RPRINT Cache_vol: 1 128 Megabyte Volumes
> RPRINT Cache_vol: Not enough space for 10 volume
> RPRINT Cache_vol: Random Volumes after clearing the disks
> RPRINT Cache_vol: volume=1 scheme=http size=128
> RPRINT Cache_vol: Random Volumes without clearing the disks
> RPRINT Cache_vol: volume=1 scheme=rtsp size=128
> =
> ==4513==ERROR: AddressSanitizer: heap-use-after-free on address 
> 0x6048e9e0 at pc 0x989546 bp 0x7fffef2a59b0 sp 0x7fffef2a59a0
> READ of size 8 at 0x6048e9e0 thread T2 ([ET_NET 1])
> #0 0x989545 in cplist_update /home/shinrich/ats/iocore/cache/Cache.cc:2702
> #1 0x989545 in cplist_reconfigure() 
> /home/shinrich/ats/iocore/cache/Cache.cc:2846
> #2 0x9d1186 in execute_and_verify(RegressionTest*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:996
> #3 0x9d2229 in RegressionTest_Cache_vol(RegressionTest*, int, int*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:842
> #4 0x76cb55f1 in start_test /home/shinrich/ats/lib/ts/Regression.cc:78
> #5 0x76cb55f1 in RegressionTest::run_some() 
> /home/shinrich/ats/lib/ts/Regression.cc:126
> #6 0x76cb5b00 in RegressionTest::check_status() 
> /home/shinrich/ats/lib/ts/Regression.cc:141
> #7 0x5404fb in RegressionCont::mainEvent(int, Event*) 
> /home/shinrich/ats/proxy/Main.cc:1210
> #8 0xb6b771 in Continuation::handleEvent(int, void*) 
> /home/shinrich/ats/iocore/eventsystem/I_Continuation.h:146
> #9 0xb6b771 in EThread::process_event(Event*, int) 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:128
> #10 0xb6d3a6 in EThread::execute() 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:207
> #11 0xb69da1 in spawn_thread_internal 
> /home/shinrich/ats/iocore/eventsystem/Thread.cc:86
> #12 0x75e27529 in start_thread (/lib64/libpthread.so.0+0x7529)
> #13 0x7464922c in __clone (/lib64/libc.so.6+0x10022c)
> 0x6048e9e0 is located 16 bytes inside of 40-byte region 
> [0x6048e9d0,0x6048e9f8)
> freed by thread T2 ([ET_NET 1]) here:
> #0 0x76f5764f in operator delete(void*) (/lib64/libasan.so.1+0x5864f)
> #1 0x9c84ac in CacheDisk::delete_volume(int) 
> /home/shinrich/ats/iocore/cache/CacheDisk.cc:330
> #2 0x989455 in cplist_update /home/shinrich/ats/iocore/cache/Cache.cc:2684
> #3 0x989455 in cplist_reconfigure() 
> /home/shinrich/ats/iocore/cache/Cache.cc:2846
> #4 0x9d1186 in execute_and_verify(RegressionTest*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:996
> #5 0x9d2229 in RegressionTest_Cache_vol(RegressionTest*, int, int*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:842
> #6 0x76cb55f1 in start_test /home/shinrich/ats/lib/ts/Regression.cc:78
> #7 0x76cb55f1 in RegressionTest::run_some() 
> /home/shinrich/ats/lib/ts/Regression.cc:126
> #8 0x76cb5b00 in RegressionTest::check_status() 
> /home/shinrich/ats/lib/ts/Regression.cc:141
> #9 0x5404fb in RegressionCont::mainEvent(int, Event*) 
> /home/shinrich/ats/proxy/Main.cc:1210
> #10 0xb6b771 in Continuation::handleEvent(int, void*) 
> /home/shinrich/ats/iocore/eventsystem/I_Continuation.h:146
> #11 0xb6b771 in EThread::process_event(Event*, int) 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:128
> #12 0xb6d3a6 in EThread::execute() 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:207
> #13 0xb69da1 in spawn_thread_internal 
> /home/shinrich/ats/iocore/eventsystem/Thread.cc:86
> #14 0x75e27529 in start_thread (/lib64/libpthread.so.0+0x7529)
> previously allocated by thread T2 ([ET_NET 1]) here:
> #0 0x76f5714f in operator new(unsigned long) 
> (/lib64/libasan.so.1+0x5814f)
> #1 0x9c770d in CacheDisk::create_volume(int, long, int) 
> /home/shinrich/ats/iocore/cache/CacheDisk.cc:296
> #2 0x98347e in create_volume /home/shinrich/ats/iocore/cache/Cache.cc:3023
> #3 0x989b41 in cplist_reconfigure() 
> /home/shinrich/ats/iocore/cache/Cache.cc:2877
> #4 0x9d1186 in execute_and_verify(RegressionTest*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:996

[jira] [Commented] (TS-3654) ASAN heap-use-after-free in cache-hosting (regression)

[ASF subversion and git services (JIRA)]

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

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

Commit 404e7866b0b7a78dfb94fbd4fb02740d065cceb0 in trafficserver's branch 
refs/heads/master from shinrich
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=404e786 ]

TS-3654: ASAN heap-use-after-free in cache-hosting (regression).


> ASAN heap-use-after-free in cache-hosting (regression)
> --
>
> Key: TS-3654
> URL: https://issues.apache.org/jira/browse/TS-3654
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Cache
>Reporter: Leif Hedstrom
>Assignee: Susan Hinrichs
> Fix For: 6.1.0
>
>
> {code}
> RPRINT Cache_vol: 1 128 Megabyte Volumes
> RPRINT Cache_vol: Not enough space for 10 volume
> RPRINT Cache_vol: Random Volumes after clearing the disks
> RPRINT Cache_vol: volume=1 scheme=http size=128
> RPRINT Cache_vol: Random Volumes without clearing the disks
> RPRINT Cache_vol: volume=1 scheme=rtsp size=128
> =
> ==3733==ERROR: AddressSanitizer: heap-use-after-free on address 
> 0x604a2960 at pc 0xa7ce83 bp 0x7f3c7f946980 sp 0x7f3c7f946970
> READ of size 8 at 0x604a2960 thread T3 ([ET_NET 2])
> #0 0xa7ce82 in cplist_update ../../../../iocore/cache/Cache.cc:3230
> #1 0xa7ce82 in cplist_reconfigure() ../../../../iocore/cache/Cache.cc:3374
> #2 0xac619e in execute_and_verify(RegressionTest*) 
> ../../../../iocore/cache/CacheHosting.cc:994
> #3 0xac75f8 in RegressionTest_Cache_vol(RegressionTest*, int, int*) 
> ../../../../iocore/cache/CacheHosting.cc:840
> #4 0x7f3c8480b4d2 in start_test ../../../../lib/ts/Regression.cc:77
> #5 0x7f3c8480b4d2 in RegressionTest::run_some() 
> ../../../../lib/ts/Regression.cc:125
> #6 0x7f3c8480b9b6 in RegressionTest::check_status() 
> ../../../../lib/ts/Regression.cc:140
> #7 0x57b5b4 in RegressionCont::mainEvent(int, Event*) 
> ../../../proxy/Main.cc:1220
> #8 0xc8b86e in Continuation::handleEvent(int, void*) 
> ../../../../iocore/eventsystem/I_Continuation.h:145
> #9 0xc8b86e in EThread::process_event(Event*, int) 
> ../../../../iocore/eventsystem/UnixEThread.cc:128
> #10 0xc8da67 in EThread::execute() 
> ../../../../iocore/eventsystem/UnixEThread.cc:207
> #11 0xc8a488 in spawn_thread_internal 
> ../../../../iocore/eventsystem/Thread.cc:85
> #12 0x7f3c84392529 in start_thread (/lib64/libpthread.so.0+0x3813e07529)
> #13 0x381370022c in __clone (/lib64/libc.so.6+0x381370022c)
> 0x604a2960 is located 16 bytes inside of 40-byte region 
> [0x604a2950,0x604a2978)
> freed by thread T3 ([ET_NET 2]) here:
> #0 0x7f3c84aaf64f in operator delete(void*) (/lib64/libasan.so.1+0x5864f)
> #1 0xabbd16 in CacheDisk::delete_volume(int) 
> ../../../../iocore/cache/CacheDisk.cc:330
> #2 0xa7bfe0 in cplist_update ../../../../iocore/cache/Cache.cc:3212
> #3 0xa7bfe0 in cplist_reconfigure() ../../../../iocore/cache/Cache.cc:3374
> #4 0xac619e in execute_and_verify(RegressionTest*) 
> ../../../../iocore/cache/CacheHosting.cc:994
> #5 0xac75f8 in RegressionTest_Cache_vol(RegressionTest*, int, int*) 
> ../../../../iocore/cache/CacheHosting.cc:840
> #6 0x7f3c8480b4d2 in start_test ../../../../lib/ts/Regression.cc:77
> #7 0x7f3c8480b4d2 in RegressionTest::run_some() 
> ../../../../lib/ts/Regression.cc:125
> #8 0x7f3c8480b9b6 in RegressionTest::check_status() 
> ../../../../lib/ts/Regression.cc:140
> #9 0x57b5b4 in RegressionCont::mainEvent(int, Event*) 
> ../../../proxy/Main.cc:1220
> #10 0xc8b86e in Continuation::handleEvent(int, void*) 
> ../../../../iocore/eventsystem/I_Continuation.h:145
> #11 0xc8b86e in EThread::process_event(Event*, int) 
> ../../../../iocore/eventsystem/UnixEThread.cc:128
> #12 0xc8da67 in EThread::execute() 
> ../../../../iocore/eventsystem/UnixEThread.cc:207
> #13 0xc8a488 in spawn_thread_internal 
> ../../../../iocore/eventsystem/Thread.cc:85
> #14 0x7f3c84392529 in start_thread (/lib64/libpthread.so.0+0x3813e07529)
> previously allocated by thread T3 ([ET_NET 2]) here:
> #0 0x7f3c84aaf14f in operator new(unsigned long) 
> (/lib64/libasan.so.1+0x5814f)
> #1 0xaba5ca in CacheDisk::create_volume(int, long, int) 
> ../../../../iocore/cache/CacheDisk.cc:296
> #2 0xa74f81 in create_volume ../../../../iocore/cache/Cache.cc:3551
> #3 0xa7ca20 in cplist_reconfigure() ../../../../iocore/cache/Cache.cc:3405
> #4 0xac619e in execute_and_verify(RegressionTest*) 
> ../../../../iocore/cache/CacheHosting.cc:994
> #5 0xac75f8 in RegressionTest_Cache_vol(RegressionTest*, int, int*) 
> ../../../../iocore/cache/CacheHosti

[jira] [Comment Edited] (TS-3775) ASAN crash while running regression test Cache_vol

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs edited comment on TS-3775 at 7/22/15 9:04 PM:
-

Sigh.  Committing a number of smaller fixes.  Looks like I mis-read my notes.  
Will update commits by hand.  Fix for this issue is not yet committed.



was (Author: shinrich):
Sigh.  Committing a number of smaller fixes.  Looks like I mis-read my notes.  
Will update commits by hand.


> ASAN crash while running regression test Cache_vol
> --
>
> Key: TS-3775
> URL: https://issues.apache.org/jira/browse/TS-3775
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Attachments: ts-3775.diff
>
>
> Seen while running master built with ASAN on FC 21.  I have a patch which 
> I'll attach and discuss in comment.
> {code}
> REGRESSION TEST Cache_vol started
> RPRINT Cache_vol: 1 128 Megabyte Volumes
> RPRINT Cache_vol: Not enough space for 10 volume
> RPRINT Cache_vol: Random Volumes after clearing the disks
> RPRINT Cache_vol: volume=1 scheme=http size=128
> RPRINT Cache_vol: Random Volumes without clearing the disks
> RPRINT Cache_vol: volume=1 scheme=rtsp size=128
> =
> ==4513==ERROR: AddressSanitizer: heap-use-after-free on address 
> 0x6048e9e0 at pc 0x989546 bp 0x7fffef2a59b0 sp 0x7fffef2a59a0
> READ of size 8 at 0x6048e9e0 thread T2 ([ET_NET 1])
> #0 0x989545 in cplist_update /home/shinrich/ats/iocore/cache/Cache.cc:2702
> #1 0x989545 in cplist_reconfigure() 
> /home/shinrich/ats/iocore/cache/Cache.cc:2846
> #2 0x9d1186 in execute_and_verify(RegressionTest*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:996
> #3 0x9d2229 in RegressionTest_Cache_vol(RegressionTest*, int, int*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:842
> #4 0x76cb55f1 in start_test /home/shinrich/ats/lib/ts/Regression.cc:78
> #5 0x76cb55f1 in RegressionTest::run_some() 
> /home/shinrich/ats/lib/ts/Regression.cc:126
> #6 0x76cb5b00 in RegressionTest::check_status() 
> /home/shinrich/ats/lib/ts/Regression.cc:141
> #7 0x5404fb in RegressionCont::mainEvent(int, Event*) 
> /home/shinrich/ats/proxy/Main.cc:1210
> #8 0xb6b771 in Continuation::handleEvent(int, void*) 
> /home/shinrich/ats/iocore/eventsystem/I_Continuation.h:146
> #9 0xb6b771 in EThread::process_event(Event*, int) 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:128
> #10 0xb6d3a6 in EThread::execute() 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:207
> #11 0xb69da1 in spawn_thread_internal 
> /home/shinrich/ats/iocore/eventsystem/Thread.cc:86
> #12 0x75e27529 in start_thread (/lib64/libpthread.so.0+0x7529)
> #13 0x7464922c in __clone (/lib64/libc.so.6+0x10022c)
> 0x6048e9e0 is located 16 bytes inside of 40-byte region 
> [0x6048e9d0,0x6048e9f8)
> freed by thread T2 ([ET_NET 1]) here:
> #0 0x76f5764f in operator delete(void*) (/lib64/libasan.so.1+0x5864f)
> #1 0x9c84ac in CacheDisk::delete_volume(int) 
> /home/shinrich/ats/iocore/cache/CacheDisk.cc:330
> #2 0x989455 in cplist_update /home/shinrich/ats/iocore/cache/Cache.cc:2684
> #3 0x989455 in cplist_reconfigure() 
> /home/shinrich/ats/iocore/cache/Cache.cc:2846
> #4 0x9d1186 in execute_and_verify(RegressionTest*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:996
> #5 0x9d2229 in RegressionTest_Cache_vol(RegressionTest*, int, int*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:842
> #6 0x76cb55f1 in start_test /home/shinrich/ats/lib/ts/Regression.cc:78
> #7 0x76cb55f1 in RegressionTest::run_some() 
> /home/shinrich/ats/lib/ts/Regression.cc:126
> #8 0x76cb5b00 in RegressionTest::check_status() 
> /home/shinrich/ats/lib/ts/Regression.cc:141
> #9 0x5404fb in RegressionCont::mainEvent(int, Event*) 
> /home/shinrich/ats/proxy/Main.cc:1210
> #10 0xb6b771 in Continuation::handleEvent(int, void*) 
> /home/shinrich/ats/iocore/eventsystem/I_Continuation.h:146
> #11 0xb6b771 in EThread::process_event(Event*, int) 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:128
> #12 0xb6d3a6 in EThread::execute() 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:207
> #13 0xb69da1 in spawn_thread_internal 
> /home/shinrich/ats/iocore/eventsystem/Thread.cc:86
> #14 0x75e27529 in start_thread (/lib64/libpthread.so.0+0x7529)
> previously allocated by thread T2 ([ET_NET 1]) here:
> #0 0x76f5714f in operator new(unsigned long) 
> (/lib64/libasan.so.1+0x5814f)
> #1 0x9c770d in CacheDisk::create_volume(int, long, int) 
> /home/shinrich/ats/iocore/cache/CacheDisk.c

[jira] [Commented] (TS-3784) Unpleasant debug assert in when starting up a SpdyClientSession

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-3784:


I mis-read my notes when setting up the commit notes on this one.  Here is the 
commit for this one.

Commit 6f66b7a18234a93e810d8ef2ce23144b9b3446f4 in trafficserver's branch 
refs/heads/master from shinrich
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6f66b7a ]
TS-3775: Adjust the mutex assignment for SpdyClientSession to avoid unlocked 
read vio.

> Unpleasant debug assert in when starting up a SpdyClientSession
> ---
>
> Key: TS-3784
> URL: https://issues.apache.org/jira/browse/TS-3784
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.1.0
>
>
> Noticed this while trying to reproduce [~oknet]'s issue on TS-3667.
> I have a callback set on the SNI hook.  It selects a new certificate and 
> reenables the vc before returning.  The stack is below.  The assert is 
> because the current thread does not hold the read.vio mutex.  In fact no 
> thread holds the read vio mutex.
> For HttpClientSession and Http2ClientSession, they use the VC's mutex instead 
> of creating new mutex.   So that shared mutex is used when setting up the 
> vio's, so when the do_io_reads occur the mutex is automatically already held. 
> If I change SpdyClientSession to use the VC mutex instead of creating a new 
> mutex, this assert does not get triggered.  Not clear whether this is causing 
> any real issues, but it seems cleaner to follow the mutex assignment strategy 
> of the other protocols.
> Here is the stack
> {code}
> #0  0x00351e4328a5 in raise () from /lib64/libc.so.6
> #1  0x00351e434085 in abort () from /lib64/libc.so.6
> #2  0x77dda215 in ink_die_die_die () at ink_error.cc:43
> #3  0x77dda2cc in ink_fatal_va(const char *, typedef __va_list_tag 
> __va_list_tag *) (
> fmt=0x77deb298 "%s:%d: failed assert `%s`", ap=0x7fffef4a8530) at 
> ink_error.cc:65
> #4  0x77dda391 in ink_fatal (message_format=0x77deb298 "%s:%d: 
> failed assert `%s`")
> at ink_error.cc:73
> #5  0x77dd7f12 in _ink_assert (
> expression=0x826e48 "vio->mutex->thread_holding == this_ethread() && 
> thread", 
> file=0x826a9e "UnixNetVConnection.cc", line=895) at ink_assert.cc:37
> #6  0x0077b4d7 in UnixNetVConnection::set_enabled 
> (this=0x7fffb801c540, vio=0x7fffb801c660)
> at UnixNetVConnection.cc:895
> #7  0x0077ab94 in UnixNetVConnection::reenable (this=0x7fffb801c540, 
> vio=0x7fffb801c660)
> at UnixNetVConnection.cc:788
> #8  0x00509755 in VIO::reenable (this=0x7fffb801c660) at 
> ../iocore/eventsystem/P_VIO.h:112
> #9  0x0077a1da in UnixNetVConnection::do_io_read 
> (this=0x7fffb801c540, c=0x7fffd402e3c0, 
> nbytes=9223372036854775807, buf=0x16f9b30) at UnixNetVConnection.cc:628
> #10 0x006393c1 in SpdyClientSession::start (this=0x7fffd402e3c0) at 
> SpdyClientSession.cc:210
> #11 0x0054a1fa in ProxyClientSession::handle_api_return 
> (this=0x7fffd402e3c0, event=6)
> at ProxyClientSession.cc:167
> #12 0x0054a142 in ProxyClientSession::do_api_callout 
> (this=0x7fffd402e3c0, 
> id=TS_HTTP_SSN_START_HOOK) at ProxyClientSession.cc:147
> #13 0x00639303 in SpdyClientSession::new_connection 
> (this=0x7fffd402e3c0, 
> new_vc=0x7fffb801c540, iobuf=0x0, reader=0x0, backdoor=false) at 
> SpdyClientSession.cc:195
> #14 0x0063878e in SpdySessionAccept::mainEvent (this=0x16bc7a0, 
> event=202, 
> edata=0x7fffb801c540) at SpdySessionAccept.cc:48
> #15 0x0050970e in Continuation::handleEvent (this=0x16bc7a0, 
> event=202, data=0x7fffb801c540)
> at ../iocore/eventsystem/I_Continuation.h:146
> #16 0x00763404 in send_plugin_event (plugin=0x16bc7a0, event=202, 
> edata=0x7fffb801c540)
> at SSLNextProtocolAccept.cc:32
> #17 0x00763b89 in SSLNextProtocolTrampoline::ioCompletionEvent 
> (this=0x7fffd40008e0, 
> event=102, edata=0x7fffb801c660) at SSLNextProtocolAccept.cc:99
> #18 0x0050970e in Continuation::handleEvent (this=0x7fffd40008e0, 
> event=102, 
> data=0x7fffb801c660) at ../iocore/eventsystem/I_Continuation.h:146
> #19 0x0077871e in read_signal_and_update (event=102, 
> vc=0x7fffb801c540)
> ---Type  to continue, or q  to quit---
> at UnixNetVConnection.cc:145
> #20 0x00778abe in read_signal_done (event=102, nh=0x7fffef9b2be0, 
> vc=0x7fffb801c540)
> at UnixNetVConnection.cc:206
> #21 0x0077baac in UnixNetVConnection::readSignalDone 
> (this=0x7fffb801c540, event=102, 
> nh=0x7fffef9b2be0) at UnixNetVConnection.cc:1006
> 

[jira] [Commented] (TS-3775) ASAN crash while running regression test Cache_vol

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-3775:


Sigh.  Committing a number of smaller fixes.  Looks like I mis-read my notes.  
Will update commits by hand.


> ASAN crash while running regression test Cache_vol
> --
>
> Key: TS-3775
> URL: https://issues.apache.org/jira/browse/TS-3775
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Attachments: ts-3775.diff
>
>
> Seen while running master built with ASAN on FC 21.  I have a patch which 
> I'll attach and discuss in comment.
> {code}
> REGRESSION TEST Cache_vol started
> RPRINT Cache_vol: 1 128 Megabyte Volumes
> RPRINT Cache_vol: Not enough space for 10 volume
> RPRINT Cache_vol: Random Volumes after clearing the disks
> RPRINT Cache_vol: volume=1 scheme=http size=128
> RPRINT Cache_vol: Random Volumes without clearing the disks
> RPRINT Cache_vol: volume=1 scheme=rtsp size=128
> =
> ==4513==ERROR: AddressSanitizer: heap-use-after-free on address 
> 0x6048e9e0 at pc 0x989546 bp 0x7fffef2a59b0 sp 0x7fffef2a59a0
> READ of size 8 at 0x6048e9e0 thread T2 ([ET_NET 1])
> #0 0x989545 in cplist_update /home/shinrich/ats/iocore/cache/Cache.cc:2702
> #1 0x989545 in cplist_reconfigure() 
> /home/shinrich/ats/iocore/cache/Cache.cc:2846
> #2 0x9d1186 in execute_and_verify(RegressionTest*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:996
> #3 0x9d2229 in RegressionTest_Cache_vol(RegressionTest*, int, int*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:842
> #4 0x76cb55f1 in start_test /home/shinrich/ats/lib/ts/Regression.cc:78
> #5 0x76cb55f1 in RegressionTest::run_some() 
> /home/shinrich/ats/lib/ts/Regression.cc:126
> #6 0x76cb5b00 in RegressionTest::check_status() 
> /home/shinrich/ats/lib/ts/Regression.cc:141
> #7 0x5404fb in RegressionCont::mainEvent(int, Event*) 
> /home/shinrich/ats/proxy/Main.cc:1210
> #8 0xb6b771 in Continuation::handleEvent(int, void*) 
> /home/shinrich/ats/iocore/eventsystem/I_Continuation.h:146
> #9 0xb6b771 in EThread::process_event(Event*, int) 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:128
> #10 0xb6d3a6 in EThread::execute() 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:207
> #11 0xb69da1 in spawn_thread_internal 
> /home/shinrich/ats/iocore/eventsystem/Thread.cc:86
> #12 0x75e27529 in start_thread (/lib64/libpthread.so.0+0x7529)
> #13 0x7464922c in __clone (/lib64/libc.so.6+0x10022c)
> 0x6048e9e0 is located 16 bytes inside of 40-byte region 
> [0x6048e9d0,0x6048e9f8)
> freed by thread T2 ([ET_NET 1]) here:
> #0 0x76f5764f in operator delete(void*) (/lib64/libasan.so.1+0x5864f)
> #1 0x9c84ac in CacheDisk::delete_volume(int) 
> /home/shinrich/ats/iocore/cache/CacheDisk.cc:330
> #2 0x989455 in cplist_update /home/shinrich/ats/iocore/cache/Cache.cc:2684
> #3 0x989455 in cplist_reconfigure() 
> /home/shinrich/ats/iocore/cache/Cache.cc:2846
> #4 0x9d1186 in execute_and_verify(RegressionTest*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:996
> #5 0x9d2229 in RegressionTest_Cache_vol(RegressionTest*, int, int*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:842
> #6 0x76cb55f1 in start_test /home/shinrich/ats/lib/ts/Regression.cc:78
> #7 0x76cb55f1 in RegressionTest::run_some() 
> /home/shinrich/ats/lib/ts/Regression.cc:126
> #8 0x76cb5b00 in RegressionTest::check_status() 
> /home/shinrich/ats/lib/ts/Regression.cc:141
> #9 0x5404fb in RegressionCont::mainEvent(int, Event*) 
> /home/shinrich/ats/proxy/Main.cc:1210
> #10 0xb6b771 in Continuation::handleEvent(int, void*) 
> /home/shinrich/ats/iocore/eventsystem/I_Continuation.h:146
> #11 0xb6b771 in EThread::process_event(Event*, int) 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:128
> #12 0xb6d3a6 in EThread::execute() 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:207
> #13 0xb69da1 in spawn_thread_internal 
> /home/shinrich/ats/iocore/eventsystem/Thread.cc:86
> #14 0x75e27529 in start_thread (/lib64/libpthread.so.0+0x7529)
> previously allocated by thread T2 ([ET_NET 1]) here:
> #0 0x76f5714f in operator new(unsigned long) 
> (/lib64/libasan.so.1+0x5814f)
> #1 0x9c770d in CacheDisk::create_volume(int, long, int) 
> /home/shinrich/ats/iocore/cache/CacheDisk.cc:296
> #2 0x98347e in create_volume /home/shinrich/ats/iocore/cache/Cache.cc:3023
> #3 0x989b41 in cplist_reconfigure() 
> /home/shinrich/ats/iocore/cache/Cache.cc:2877
> #4 0x9d1186 in execute_and_verify(Regressio

Build failed in Jenkins: tsqa-master #717

[jenkins]

See 

Changes:

[shinrich] Trying clang format again.

--
[...truncated 506 lines...]
INFO 2015-07-22 20:48:16,856 - sending data back to the client
INFO 2015-07-22 20:48:19,258 - sending data back to the client
INFO 2015-07-22 20:48:21,661 - sending data back to the client
INFO 2015-07-22 20:48:25,666 - sending data back to the client
ok
test_chunked_keepalive_server (test_chunked.TestChunked) ... INFO 2015-07-22 
20:48:29,670 - sending data back to the client
INFO 2015-07-22 20:48:32,672 - sending data back to the client
ok
Test that the origin does in fact support keepalive ... INFO 2015-07-22 
20:48:33,676 - sending data back to the client
INFO 2015-07-22 20:48:36,680 - sending data back to the client
INFO 2015-07-22 20:48:37,684 - sending data back to the client
INFO 2015-07-22 20:48:39,685 - Client disconnected
INFO 2015-07-22 20:48:40,087 - sending data back to the client
INFO 2015-07-22 20:48:40,489 - sending data back to the client
INFO 2015-07-22 20:48:42,489 - Client disconnected
INFO 2015-07-22 20:48:44,494 - sending data back to the client
ok
INFO 2015-07-22 20:48:46,504 - Client disconnected
INFO 2015-07-22 20:48:46,697 - Environment prefix is /tmp/tsqa.env.uGuQ3Z
INFO 2015-07-22 20:48:48,499 - Client disconnected
Verify that we get 502s from an origin which just did a bind ... ok
Verify that we get 200s from origins that delayed_accept_after_connect ... ok
Verify that we get 504s from origins that die_on_connect ... ok
Verify that we get 502s from origins that bind + listen ... ok
Verify that we get 504s from origins that return a partial_response ... FAIL
Verify that we get 200s from origins that reset_after_accept ... FAIL
INFO 2015-07-22 20:48:57,010 - Environment prefix is /tmp/tsqa.env.Tfv8CM
test_default_404 (test_example.TestBootstrap) ... ok
Test that traffic_line works, and verify that the values for proxy.config ... ok
INFO 2015-07-22 20:49:26,913 - Starting build 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-07-22 20:50:23,356 - Build completed 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-07-22 20:50:23,428 - Environment prefix is /tmp/tsqa.env.RQmRUv
test_spdy (test_example.TestConfigureFlags) ... ok
INFO 2015-07-22 20:50:26,835 - Environment prefix is /tmp/tsqa.env.jm2YnW
test_basic_proxy (test_example.TestDynamicHTTPEndpointCase) ... 127.0.0.1 - - 
[22/Jul/2015 20:50:30] "GET /test HTTP/1.1" 404 0
ok
INFO 2015-07-22 20:50:30,244 - Environment prefix is /tmp/tsqa.env.Im6NB0
test_logs_exist (test_example.TestLogRefCounting) ... 127.0.0.1 - - 
[22/Jul/2015 20:50:33] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:50:33] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:50:33] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:50:33] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:50:33] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:50:33] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:50:33] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:50:33] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:50:33] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:50:33] "GET / HTTP/1.1" 404 0
FAIL
INFO 2015-07-22 20:50:43,728 - Environment prefix is /tmp/tsqa.env.D1HaM0
test_logs_exist (test_example.TestLogs) ... FAIL
SKIP: Skip the entire class
INFO 2015-07-22 20:50:57,172 - Environment prefix is /tmp/tsqa.env.ZrpCw6
test_basic_intercept (test_example.TestServerIntercept) ... 127.0.0.1 - - 
[22/Jul/2015 20:51:00] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:51:00] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:51:00] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:51:00] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:51:00] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:51:00] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:51:00] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:51:00] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:51:00] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:51:00] "GET / HTTP/1.1" 200 5
ok
INFO 2015-07-22 20:51:00,635 - Environment prefix is /tmp/tsqa.env.f_7I9A
test_lookup_timeout (test_hostdb.TestHostDBFailedDNS) ... ok
INFO 2015-07-22 20:51:06,062 - Environment prefix is /tmp/tsqa.env.Mya09_
Test basic fnctionality of hosts files ... ok
Test that changes to hosts file get loaded within host_file.interval ... ok
INFO 2015-07-22 20:51:15,533 - Environment prefix is /tmp/tsqa.env.eaoSsk
SKIP: 
 >> begin captured logging << 
root: INFO: Environment prefix i

[jira] [Resolved] (TS-3784) Unpleasant debug assert in when starting up a SpdyClientSession

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs resolved TS-3784.

Resolution: Fixed

> Unpleasant debug assert in when starting up a SpdyClientSession
> ---
>
> Key: TS-3784
> URL: https://issues.apache.org/jira/browse/TS-3784
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SPDY
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.1.0
>
>
> Noticed this while trying to reproduce [~oknet]'s issue on TS-3667.
> I have a callback set on the SNI hook.  It selects a new certificate and 
> reenables the vc before returning.  The stack is below.  The assert is 
> because the current thread does not hold the read.vio mutex.  In fact no 
> thread holds the read vio mutex.
> For HttpClientSession and Http2ClientSession, they use the VC's mutex instead 
> of creating new mutex.   So that shared mutex is used when setting up the 
> vio's, so when the do_io_reads occur the mutex is automatically already held. 
> If I change SpdyClientSession to use the VC mutex instead of creating a new 
> mutex, this assert does not get triggered.  Not clear whether this is causing 
> any real issues, but it seems cleaner to follow the mutex assignment strategy 
> of the other protocols.
> Here is the stack
> {code}
> #0  0x00351e4328a5 in raise () from /lib64/libc.so.6
> #1  0x00351e434085 in abort () from /lib64/libc.so.6
> #2  0x77dda215 in ink_die_die_die () at ink_error.cc:43
> #3  0x77dda2cc in ink_fatal_va(const char *, typedef __va_list_tag 
> __va_list_tag *) (
> fmt=0x77deb298 "%s:%d: failed assert `%s`", ap=0x7fffef4a8530) at 
> ink_error.cc:65
> #4  0x77dda391 in ink_fatal (message_format=0x77deb298 "%s:%d: 
> failed assert `%s`")
> at ink_error.cc:73
> #5  0x77dd7f12 in _ink_assert (
> expression=0x826e48 "vio->mutex->thread_holding == this_ethread() && 
> thread", 
> file=0x826a9e "UnixNetVConnection.cc", line=895) at ink_assert.cc:37
> #6  0x0077b4d7 in UnixNetVConnection::set_enabled 
> (this=0x7fffb801c540, vio=0x7fffb801c660)
> at UnixNetVConnection.cc:895
> #7  0x0077ab94 in UnixNetVConnection::reenable (this=0x7fffb801c540, 
> vio=0x7fffb801c660)
> at UnixNetVConnection.cc:788
> #8  0x00509755 in VIO::reenable (this=0x7fffb801c660) at 
> ../iocore/eventsystem/P_VIO.h:112
> #9  0x0077a1da in UnixNetVConnection::do_io_read 
> (this=0x7fffb801c540, c=0x7fffd402e3c0, 
> nbytes=9223372036854775807, buf=0x16f9b30) at UnixNetVConnection.cc:628
> #10 0x006393c1 in SpdyClientSession::start (this=0x7fffd402e3c0) at 
> SpdyClientSession.cc:210
> #11 0x0054a1fa in ProxyClientSession::handle_api_return 
> (this=0x7fffd402e3c0, event=6)
> at ProxyClientSession.cc:167
> #12 0x0054a142 in ProxyClientSession::do_api_callout 
> (this=0x7fffd402e3c0, 
> id=TS_HTTP_SSN_START_HOOK) at ProxyClientSession.cc:147
> #13 0x00639303 in SpdyClientSession::new_connection 
> (this=0x7fffd402e3c0, 
> new_vc=0x7fffb801c540, iobuf=0x0, reader=0x0, backdoor=false) at 
> SpdyClientSession.cc:195
> #14 0x0063878e in SpdySessionAccept::mainEvent (this=0x16bc7a0, 
> event=202, 
> edata=0x7fffb801c540) at SpdySessionAccept.cc:48
> #15 0x0050970e in Continuation::handleEvent (this=0x16bc7a0, 
> event=202, data=0x7fffb801c540)
> at ../iocore/eventsystem/I_Continuation.h:146
> #16 0x00763404 in send_plugin_event (plugin=0x16bc7a0, event=202, 
> edata=0x7fffb801c540)
> at SSLNextProtocolAccept.cc:32
> #17 0x00763b89 in SSLNextProtocolTrampoline::ioCompletionEvent 
> (this=0x7fffd40008e0, 
> event=102, edata=0x7fffb801c660) at SSLNextProtocolAccept.cc:99
> #18 0x0050970e in Continuation::handleEvent (this=0x7fffd40008e0, 
> event=102, 
> data=0x7fffb801c660) at ../iocore/eventsystem/I_Continuation.h:146
> #19 0x0077871e in read_signal_and_update (event=102, 
> vc=0x7fffb801c540)
> ---Type  to continue, or q  to quit---
> at UnixNetVConnection.cc:145
> #20 0x00778abe in read_signal_done (event=102, nh=0x7fffef9b2be0, 
> vc=0x7fffb801c540)
> at UnixNetVConnection.cc:206
> #21 0x0077baac in UnixNetVConnection::readSignalDone 
> (this=0x7fffb801c540, event=102, 
> nh=0x7fffef9b2be0) at UnixNetVConnection.cc:1006
> #22 0x0075e559 in SSLNetVConnection::net_read_io 
> (this=0x7fffb801c540, nh=0x7fffef9b2be0, 
> lthread=0x7fffef9af010) at SSLNetVConnection.cc:543
> #23 0x00770b52 in NetHandler::mainNetEvent (this=0x7fffef9b2be0, 
> event=5, e=0x1153690)
> at UnixNet.cc:516
> #24 0x0050970e in Continuation::handleEvent (this=0x7fffef9b2be0, 
> event=5, data=0x1153690)
> at ../iocor

[jira] [Updated] (TS-3788) SNI callbacks stall after TS-3667 fix

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs updated TS-3788:
---
Backport to Version: 5.3.2, 6.0.0

> SNI callbacks stall after TS-3667 fix
> -
>
> Key: TS-3788
> URL: https://issues.apache.org/jira/browse/TS-3788
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.1.0
>
>
> Reported by [~oknet] and the main discussion is in the TS-3667.  Due to 
> changes in the fix for TS-3667, the EAGAIN would get checked before calling 
> SSL_accept.  If SSL_accept state machine needed to write data, it would never 
> get triggered and the handshake would stall.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (TS-3788) SNI callbacks stall after TS-3667 fix

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs resolved TS-3788.

Resolution: Fixed

> SNI callbacks stall after TS-3667 fix
> -
>
> Key: TS-3788
> URL: https://issues.apache.org/jira/browse/TS-3788
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.1.0
>
>
> Reported by [~oknet] and the main discussion is in the TS-3667.  Due to 
> changes in the fix for TS-3667, the EAGAIN would get checked before calling 
> SSL_accept.  If SSL_accept state machine needed to write data, it would never 
> get triggered and the handshake would stall.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Resolved] (TS-3790) action=tunnel in ssl_multicert.config will cause crash

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs resolved TS-3790.

Resolution: Fixed

> action=tunnel in ssl_multicert.config will cause crash
> --
>
> Key: TS-3790
> URL: https://issues.apache.org/jira/browse/TS-3790
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.1.0
>
> Attachments: ts-3790.diff
>
>
> Enabled an old line in my ssl_multicert.config and accidentally tested the 
> action=tunnel feature.  It caused the traffic_server process to crash.  The 
> code was assuming that a handShakeBuffer must be present if we are deciding 
> to do a blind tunnel, but that is only the case if the decision is made in 
> the SNI callback.  I'm going to attach a patch that fixes the problem.
> Example line that will trigger the issue.  Packets addressed to 1.2.3.4 will 
> try to convert to blind tunnel before any SSL handshake processing is 
> attempted.
> {code}
> dest_ip=1.2.3.4 action=tunnel ssl_cert_name=servercert.pem 
> ssl_key_name=privkey.pem
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Build failed in Jenkins: tsqa-master #716

[jenkins]

See 

Changes:

[shinrich] TS-3790: action=tunnel attribute will cause crash.

[shinrich] TS-3788: SNI Callbacks stall after TS-3667 fix

[shinrich] Clang format and fix compiler warning.

--
[...truncated 505 lines...]
INFO 2015-07-22 20:40:42,707 - sending data back to the client
INFO 2015-07-22 20:40:45,109 - sending data back to the client
INFO 2015-07-22 20:40:47,512 - sending data back to the client
INFO 2015-07-22 20:40:51,518 - sending data back to the client
ok
test_chunked_keepalive_server (test_chunked.TestChunked) ... INFO 2015-07-22 
20:40:55,521 - sending data back to the client
INFO 2015-07-22 20:40:58,525 - sending data back to the client
ok
Test that the origin does in fact support keepalive ... INFO 2015-07-22 
20:40:59,529 - sending data back to the client
INFO 2015-07-22 20:41:02,534 - sending data back to the client
INFO 2015-07-22 20:41:03,538 - sending data back to the client
INFO 2015-07-22 20:41:05,539 - Client disconnected
INFO 2015-07-22 20:41:05,942 - sending data back to the client
INFO 2015-07-22 20:41:06,344 - sending data back to the client
INFO 2015-07-22 20:41:08,345 - Client disconnected
INFO 2015-07-22 20:41:10,348 - sending data back to the client
ok
INFO 2015-07-22 20:41:12,360 - Client disconnected
INFO 2015-07-22 20:41:12,550 - Environment prefix is /tmp/tsqa.env.ZiUf_r
INFO 2015-07-22 20:41:14,354 - Client disconnected
Verify that we get 502s from an origin which just did a bind ... ok
Verify that we get 200s from origins that delayed_accept_after_connect ... ok
Verify that we get 504s from origins that die_on_connect ... ok
Verify that we get 502s from origins that bind + listen ... ok
Verify that we get 504s from origins that return a partial_response ... FAIL
Verify that we get 200s from origins that reset_after_accept ... FAIL
INFO 2015-07-22 20:41:23,860 - Environment prefix is /tmp/tsqa.env.B_A7qF
test_default_404 (test_example.TestBootstrap) ... ok
Test that traffic_line works, and verify that the values for proxy.config ... ok
INFO 2015-07-22 20:41:55,594 - Starting build 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-07-22 20:42:57,184 - Build completed 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-07-22 20:42:57,248 - Environment prefix is /tmp/tsqa.env.i20AB3
test_spdy (test_example.TestConfigureFlags) ... ok
INFO 2015-07-22 20:43:00,650 - Environment prefix is /tmp/tsqa.env.kh5Gi2
test_basic_proxy (test_example.TestDynamicHTTPEndpointCase) ... 127.0.0.1 - - 
[22/Jul/2015 20:43:03] "GET /test HTTP/1.1" 404 0
ok
INFO 2015-07-22 20:43:04,076 - Environment prefix is /tmp/tsqa.env.8sJvH7
test_logs_exist (test_example.TestLogRefCounting) ... 127.0.0.1 - - 
[22/Jul/2015 20:43:07] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:43:07] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:43:07] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:43:07] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:43:07] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:43:07] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:43:07] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:43:07] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:43:07] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:43:07] "GET / HTTP/1.1" 404 0
FAIL
INFO 2015-07-22 20:43:17,556 - Environment prefix is /tmp/tsqa.env.66zYrx
test_logs_exist (test_example.TestLogs) ... FAIL
SKIP: Skip the entire class
INFO 2015-07-22 20:43:31,099 - Environment prefix is /tmp/tsqa.env.n8vcgv
test_basic_intercept (test_example.TestServerIntercept) ... 127.0.0.1 - - 
[22/Jul/2015 20:43:34] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:43:34] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:43:34] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:43:34] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:43:34] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:43:34] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:43:34] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:43:34] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:43:34] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:43:34] "GET / HTTP/1.1" 200 5
ok
INFO 2015-07-22 20:43:34,562 - Environment prefix is /tmp/tsqa.env.WQFxVW
test_lookup_timeout (test_hostdb.TestHostDBFailedDNS) ... ok
INFO 2015-07-22 20:43:39,992 - Environment prefix is /tmp/tsqa.env.vpRMrt
Test basic fnctionality of hosts files ... ok
Test that changes to hosts file get loaded within host_file.interval ... ok
INFO 2015-07-22 20:43:49,465 - Environment prefix 

Jenkins build is back to normal : clang-format #49

[jenkins]

See 

Build failed in Jenkins: tsqa-master #715

[jenkins]

See 

Changes:

[shinrich] TS-3775:  Adjust the mutex assignment for SpdyClientSession to avoid 
unlocked read vio.

--
[...truncated 508 lines...]
INFO 2015-07-22 20:27:38,110 - sending data back to the client
INFO 2015-07-22 20:27:40,514 - sending data back to the client
INFO 2015-07-22 20:27:42,917 - sending data back to the client
INFO 2015-07-22 20:27:46,919 - sending data back to the client
ok
test_chunked_keepalive_server (test_chunked.TestChunked) ... INFO 2015-07-22 
20:27:50,924 - sending data back to the client
INFO 2015-07-22 20:27:53,929 - sending data back to the client
ok
Test that the origin does in fact support keepalive ... INFO 2015-07-22 
20:27:54,933 - sending data back to the client
INFO 2015-07-22 20:27:57,938 - sending data back to the client
INFO 2015-07-22 20:27:58,941 - sending data back to the client
INFO 2015-07-22 20:28:00,943 - Client disconnected
INFO 2015-07-22 20:28:01,345 - sending data back to the client
INFO 2015-07-22 20:28:01,747 - sending data back to the client
INFO 2015-07-22 20:28:03,748 - Client disconnected
INFO 2015-07-22 20:28:05,751 - sending data back to the client
ok
INFO 2015-07-22 20:28:07,762 - Client disconnected
INFO 2015-07-22 20:28:07,954 - Environment prefix is /tmp/tsqa.env.WGGtAl
INFO 2015-07-22 20:28:09,757 - Client disconnected
Verify that we get 502s from an origin which just did a bind ... ok
Verify that we get 200s from origins that delayed_accept_after_connect ... ok
Verify that we get 504s from origins that die_on_connect ... ok
Verify that we get 502s from origins that bind + listen ... ok
Verify that we get 504s from origins that return a partial_response ... FAIL
Verify that we get 200s from origins that reset_after_accept ... FAIL
INFO 2015-07-22 20:28:18,256 - Environment prefix is /tmp/tsqa.env.Op_G3l
test_default_404 (test_example.TestBootstrap) ... ok
Test that traffic_line works, and verify that the values for proxy.config ... ok
INFO 2015-07-22 20:28:48,244 - Starting build 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-07-22 20:29:40,048 - Build completed 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-07-22 20:29:40,114 - Environment prefix is /tmp/tsqa.env.XTjcrw
test_spdy (test_example.TestConfigureFlags) ... ok
INFO 2015-07-22 20:29:43,517 - Environment prefix is /tmp/tsqa.env.eXo8w2
test_basic_proxy (test_example.TestDynamicHTTPEndpointCase) ... 127.0.0.1 - - 
[22/Jul/2015 20:29:46] "GET /test HTTP/1.1" 404 0
ok
INFO 2015-07-22 20:29:46,926 - Environment prefix is /tmp/tsqa.env.C2YrJ4
test_logs_exist (test_example.TestLogRefCounting) ... 127.0.0.1 - - 
[22/Jul/2015 20:29:50] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:29:50] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:29:50] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:29:50] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:29:50] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:29:50] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:29:50] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:29:50] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:29:50] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 20:29:50] "GET / HTTP/1.1" 404 0
FAIL
INFO 2015-07-22 20:30:00,403 - Environment prefix is /tmp/tsqa.env.lKy0uB
test_logs_exist (test_example.TestLogs) ... FAIL
SKIP: Skip the entire class
INFO 2015-07-22 20:30:13,846 - Environment prefix is /tmp/tsqa.env.ZOmpRn
test_basic_intercept (test_example.TestServerIntercept) ... 127.0.0.1 - - 
[22/Jul/2015 20:30:17] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:30:17] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:30:17] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:30:17] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:30:17] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:30:17] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:30:17] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:30:17] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:30:17] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 20:30:17] "GET / HTTP/1.1" 200 5
ok
INFO 2015-07-22 20:30:17,296 - Environment prefix is /tmp/tsqa.env.Vjvic8
test_lookup_timeout (test_hostdb.TestHostDBFailedDNS) ... ok
INFO 2015-07-22 20:30:22,716 - Environment prefix is /tmp/tsqa.env.cDx4eR
Test basic fnctionality of hosts files ... ok
Test that changes to hosts file get loaded within host_file.interval ... ok
INFO 2015-07-22 20:30:32,181 - Environment prefix is /tmp/tsqa.env.fR1Z8m
SKIP: 
 >> begin captured lo

Build failed in Jenkins: clang-format #48

[jenkins]

See 

Changes:

[shinrich] Clang format and fix compiler warning.

--
[...truncated 4255 lines...]
+ clang-format -i src/proxy/ICP.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/ProxyClientSession.h
src/proxy/ProxyClientSession.h
+ clang-format -i src/proxy/ProxyClientSession.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/CacheControl.h
src/proxy/CacheControl.h
+ clang-format -i src/proxy/CacheControl.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/InkAPITestTool.cc
src/proxy/InkAPITestTool.cc
+ clang-format -i src/proxy/InkAPITestTool.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/ControlBase.cc
src/proxy/ControlBase.cc
+ clang-format -i src/proxy/ControlBase.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2ClientSession.cc
src/proxy/http2/Http2ClientSession.cc
+ clang-format -i src/proxy/http2/Http2ClientSession.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2ConnectionState.h
src/proxy/http2/Http2ConnectionState.h
+ clang-format -i src/proxy/http2/Http2ConnectionState.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/test_Huffmancode.cc
src/proxy/http2/test_Huffmancode.cc
+ clang-format -i src/proxy/http2/test_Huffmancode.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2SessionAccept.h
src/proxy/http2/Http2SessionAccept.h
+ clang-format -i src/proxy/http2/Http2SessionAccept.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HuffmanCodec.h
src/proxy/http2/HuffmanCodec.h
+ clang-format -i src/proxy/http2/HuffmanCodec.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2ConnectionState.cc
src/proxy/http2/Http2ConnectionState.cc
+ clang-format -i src/proxy/http2/Http2ConnectionState.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HTTP2.cc
src/proxy/http2/HTTP2.cc
+ clang-format -i src/proxy/http2/HTTP2.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2ClientSession.h
src/proxy/http2/Http2ClientSession.h
+ clang-format -i src/proxy/http2/Http2ClientSession.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HPACK.h
src/proxy/http2/HPACK.h
+ clang-format -i src/proxy/http2/HPACK.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HTTP2.h
src/proxy/http2/HTTP2.h
+ clang-format -i src/proxy/http2/HTTP2.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HuffmanCodec.cc
src/proxy/http2/HuffmanCodec.cc
+ clang-format -i src/proxy/http2/HuffmanCodec.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2SessionAccept.cc
src/proxy/http2/Http2SessionAccept.cc
+ clang-format -i src/proxy/http2/Http2SessionAccept.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HPACK.cc
src/proxy/http2/HPACK.cc
+ clang-format -i src/proxy/http2/HPACK.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/Main.cc
src/proxy/Main.cc
+ clang-format -i src/proxy/Main.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/UDPAPIClientTest.cc
src/proxy/UDPAPIClientTest.cc
+ clang-format -i src/proxy/UDPAPIClientTest.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/Plugin.cc
src/proxy/Plugin.cc
+ clang-format -i src/proxy/Plugin.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/TestClock.cc
src/proxy/TestClock.cc
+ clang-format -i src/proxy/TestClock.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/UDPAPIClientTest.h
src/proxy/UDPAPIClientTest.h
+ clang-format -i src/proxy/UDPAPIClientTest.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/prox

Jenkins build is back to normal : in_tree-master #1238

[jenkins]

See 

Build failed in Jenkins: clang-format #47

[jenkins]

See 

Changes:

[shinrich] TS-3790: action=tunnel attribute will cause crash.

[shinrich] TS-3788: SNI Callbacks stall after TS-3667 fix

--
[...truncated 4267 lines...]
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/InkAPITestTool.cc
src/proxy/InkAPITestTool.cc
+ clang-format -i src/proxy/InkAPITestTool.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/ControlBase.cc
src/proxy/ControlBase.cc
+ clang-format -i src/proxy/ControlBase.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2ClientSession.cc
src/proxy/http2/Http2ClientSession.cc
+ clang-format -i src/proxy/http2/Http2ClientSession.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2ConnectionState.h
src/proxy/http2/Http2ConnectionState.h
+ clang-format -i src/proxy/http2/Http2ConnectionState.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/test_Huffmancode.cc
src/proxy/http2/test_Huffmancode.cc
+ clang-format -i src/proxy/http2/test_Huffmancode.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2SessionAccept.h
src/proxy/http2/Http2SessionAccept.h
+ clang-format -i src/proxy/http2/Http2SessionAccept.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HuffmanCodec.h
src/proxy/http2/HuffmanCodec.h
+ clang-format -i src/proxy/http2/HuffmanCodec.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2ConnectionState.cc
src/proxy/http2/Http2ConnectionState.cc
+ clang-format -i src/proxy/http2/Http2ConnectionState.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HTTP2.cc
src/proxy/http2/HTTP2.cc
+ clang-format -i src/proxy/http2/HTTP2.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2ClientSession.h
src/proxy/http2/Http2ClientSession.h
+ clang-format -i src/proxy/http2/Http2ClientSession.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HPACK.h
src/proxy/http2/HPACK.h
+ clang-format -i src/proxy/http2/HPACK.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HTTP2.h
src/proxy/http2/HTTP2.h
+ clang-format -i src/proxy/http2/HTTP2.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HuffmanCodec.cc
src/proxy/http2/HuffmanCodec.cc
+ clang-format -i src/proxy/http2/HuffmanCodec.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2SessionAccept.cc
src/proxy/http2/Http2SessionAccept.cc
+ clang-format -i src/proxy/http2/Http2SessionAccept.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HPACK.cc
src/proxy/http2/HPACK.cc
+ clang-format -i src/proxy/http2/HPACK.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/Main.cc
src/proxy/Main.cc
+ clang-format -i src/proxy/Main.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/UDPAPIClientTest.cc
src/proxy/UDPAPIClientTest.cc
+ clang-format -i src/proxy/UDPAPIClientTest.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/Plugin.cc
src/proxy/Plugin.cc
+ clang-format -i src/proxy/Plugin.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/TestClock.cc
src/proxy/TestClock.cc
+ clang-format -i src/proxy/TestClock.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/UDPAPIClientTest.h
src/proxy/UDPAPIClientTest.h
+ clang-format -i src/proxy/UDPAPIClientTest.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/ICPProcessor.h
src/proxy/ICPProcessor.h
+ clang-format -i src/proxy/ICPProcessor.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/InkAPITest.cc
src/proxy/InkAPITest.cc
+ clang-format -i src/proxy/InkAPITest.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'

Build failed in Jenkins: out_of_tree-master #1027

[jenkins]

See 

Changes:

[shinrich] TS-3790: action=tunnel attribute will cause crash.

[shinrich] TS-3788: SNI Callbacks stall after TS-3667 fix

--
[...truncated 2478 lines...]
libtool: link: /bin/nm -B  .libs/escalate.o   | sed -n -e 's/^.*[
]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][  
]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' | /bin/sed 
's/.* //' | sort | uniq > .libs/escalate.exp
libtool: link: /bin/grep -E -e 
"^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$"
 ".libs/escalate.exp" > ".libs/escalate.expT"
libtool: link: mv -f ".libs/escalate.expT" ".libs/escalate.exp"
libtool: link: c++  -fPIC -DPIC -shared -nostdlib 
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/crti.o 
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/crtbeginS.o  .libs/escalate.o   -lcap 
-lpcre -llzma -lz -lcrypt -lpthread -ldl -lxml2 
-L/usr/lib/gcc/x86_64-redhat-linux/4.8.3 
-L/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64 -L/lib/../lib64 
-L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../.. -lstdc++ 
-lm -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.8.3/crtendS.o 
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/crtn.o  -O3 -mcx16   
-Wl,-soname -Wl,escalate.so -Wl,-retain-symbols-file -Wl,.libs/escalate.exp -o 
.libs/escalate.so
libtool: link: ( cd ".libs" && rm -f "escalate.la" && ln -s "../escalate.la" 
"escalate.la" )
make[3]: Leaving directory 
`
Making all in esi
make[3]: Entering directory 
`
depbase=`echo esi.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../../libtool  --tag=CXX   --mode=compile ccache c++ -DHAVE_CONFIG_H 
-I. -I../../../../plugins/experimental/esi -I../../../lib  -I../../../proxy/api 
-I../../../../proxy/api -I../../../../lib 
-I../../../../plugins/experimental/esi/lib 
-I../../../../plugins/experimental/esi/fetcher 
-I../../../../plugins/experimental/esi/test -Dlinux -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 
-D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/include/libxml2 
-Wno-deprecated -std=c++11 -g -pipe -Wall -O3 -feliminate-unused-debug-symbols 
-fno-strict-aliasing -Werror -Wno-invalid-offsetof -mcx16 -MT esi.lo -MD -MP 
-MF $depbase.Tpo -c -o esi.lo ../../../../plugins/experimental/esi/esi.cc &&\
mv -f $depbase.Tpo $depbase.Plo
depbase=`echo serverIntercept.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../../libtool  --tag=CXX   --mode=compile ccache c++ -DHAVE_CONFIG_H 
-I. -I../../../../plugins/experimental/esi -I../../../lib  -I../../../proxy/api 
-I../../../../proxy/api -I../../../../lib 
-I../../../../plugins/experimental/esi/lib 
-I../../../../plugins/experimental/esi/fetcher 
-I../../../../plugins/experimental/esi/test -Dlinux -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 
-D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/include/libxml2 
-Wno-deprecated -std=c++11 -g -pipe -Wall -O3 -feliminate-unused-debug-symbols 
-fno-strict-aliasing -Werror -Wno-invalid-offsetof -mcx16 -MT 
serverIntercept.lo -MD -MP -MF $depbase.Tpo -c -o serverIntercept.lo 
../../../../plugins/experimental/esi/serverIntercept.cc &&\
mv -f $depbase.Tpo $depbase.Plo
depbase=`echo combo_handler.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../../libtool  --tag=CXX   --mode=compile ccache c++ -DHAVE_CONFIG_H 
-I. -I../../../../plugins/experimental/esi -I../../../lib  -I../../../proxy/api 
-I../../../../proxy/api -I../../../../lib 
-I../../../../plugins/experimental/esi/lib 
-I../../../../plugins/experimental/esi/fetcher 
-I../../../../plugins/experimental/esi/test -Dlinux -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 
-D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/include/libxml2 
-Wno-deprecated -std=c++11 -g -pipe -Wall -O3 -feliminate-unused-debug-symbols 
-fno-strict-aliasing -Werror -Wno-invalid-offsetof -mcx16 -MT combo_handler.lo 
-MD -MP -MF $depbase.Tpo -c -o combo_handler.lo 
../../../../plugins/experimental/esi/combo_handler.cc &&\
mv -f $depbase.Tpo $depbase.Plo
depbase=`echo lib/DocNode.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../../libtool  --tag=CXX   --mode=compile ccache c++ -DHAVE_CONFIG_H 
-I. -I../../../../plugins/experimental/esi -I../../../lib  -I../../../proxy/api 
-I../../../../proxy/api -I../../../../lib 
-I../../../../plugins/experimental/esi/lib 
-I../../../../plugins/experimental/esi/fetcher 
-I../../../../plugins/experimental/esi/test -Dlinux -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LI

[jira] [Updated] (TS-3790) action=tunnel in ssl_multicert.config will cause crash

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs updated TS-3790:
---
Fix Version/s: 6.1.0

> action=tunnel in ssl_multicert.config will cause crash
> --
>
> Key: TS-3790
> URL: https://issues.apache.org/jira/browse/TS-3790
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.1.0
>
> Attachments: ts-3790.diff
>
>
> Enabled an old line in my ssl_multicert.config and accidentally tested the 
> action=tunnel feature.  It caused the traffic_server process to crash.  The 
> code was assuming that a handShakeBuffer must be present if we are deciding 
> to do a blind tunnel, but that is only the case if the decision is made in 
> the SNI callback.  I'm going to attach a patch that fixes the problem.
> Example line that will trigger the issue.  Packets addressed to 1.2.3.4 will 
> try to convert to blind tunnel before any SSL handshake processing is 
> attempted.
> {code}
> dest_ip=1.2.3.4 action=tunnel ssl_cert_name=servercert.pem 
> ssl_key_name=privkey.pem
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Build failed in Jenkins: in_tree-master #1237

[jenkins]

See 

Changes:

[shinrich] TS-3790: action=tunnel attribute will cause crash.

[shinrich] TS-3788: SNI Callbacks stall after TS-3667 fix

--
[...truncated 2887 lines...]
libtool: link: /bin/nm -B  .libs/escalate.o   | sed -n -e 's/^.*[
]\([ABCDGIRSTW][ABCDGIRSTW]*\)[ ][  
]*\([_A-Za-z][_A-Za-z0-9]*\)$/\1 \2 \2/p' | sed '/ __gnu_lto/d' | /bin/sed 
's/.* //' | sort | uniq > .libs/escalate.exp
libtool: link: /bin/grep -E -e 
"^(TSRemapInit|TSRemapDone|TSRemapDoRemap|TSRemapNewInstance|TSRemapDeleteInstance|TSRemapOSResponse|TSPluginInit)$"
 ".libs/escalate.exp" > ".libs/escalate.expT"
libtool: link: mv -f ".libs/escalate.expT" ".libs/escalate.exp"
libtool: link: c++  -fPIC -DPIC -shared -nostdlib 
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/crti.o 
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/crtbeginS.o  .libs/escalate.o   -lcap 
-lpcre -llzma -lz -lcrypt -lpthread -ldl -lxml2 
-L/usr/lib/gcc/x86_64-redhat-linux/4.8.3 
-L/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64 -L/lib/../lib64 
-L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../.. -lstdc++ 
-lm -lc -lgcc_s /usr/lib/gcc/x86_64-redhat-linux/4.8.3/crtendS.o 
/usr/lib/gcc/x86_64-redhat-linux/4.8.3/../../../../lib64/crtn.o  -O3 -mcx16   
-Wl,-soname -Wl,escalate.so -Wl,-retain-symbols-file -Wl,.libs/escalate.exp -o 
.libs/escalate.so
libtool: link: ( cd ".libs" && rm -f "escalate.la" && ln -s "../escalate.la" 
"escalate.la" )
make[3]: Leaving directory 
`
Making all in esi
make[3]: Entering directory 
`
depbase=`echo esi.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../../libtool  --tag=CXX   --mode=compile ccache c++ -DHAVE_CONFIG_H 
-I. -I../../../lib  -I../../../proxy/api -I../../../proxy/api -I../../../lib 
-I./lib -I./fetcher -I./test -Dlinux -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 
-D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/include/libxml2 
-Wno-deprecated -std=c++11 -g -pipe -Wall -O3 -feliminate-unused-debug-symbols 
-fno-strict-aliasing -Werror -Wno-invalid-offsetof -mcx16 -MT esi.lo -MD -MP 
-MF $depbase.Tpo -c -o esi.lo esi.cc &&\
mv -f $depbase.Tpo $depbase.Plo
depbase=`echo serverIntercept.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../../libtool  --tag=CXX   --mode=compile ccache c++ -DHAVE_CONFIG_H 
-I. -I../../../lib  -I../../../proxy/api -I../../../proxy/api -I../../../lib 
-I./lib -I./fetcher -I./test -Dlinux -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 
-D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/include/libxml2 
-Wno-deprecated -std=c++11 -g -pipe -Wall -O3 -feliminate-unused-debug-symbols 
-fno-strict-aliasing -Werror -Wno-invalid-offsetof -mcx16 -MT 
serverIntercept.lo -MD -MP -MF $depbase.Tpo -c -o serverIntercept.lo 
serverIntercept.cc &&\
mv -f $depbase.Tpo $depbase.Plo
depbase=`echo combo_handler.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../../libtool  --tag=CXX   --mode=compile ccache c++ -DHAVE_CONFIG_H 
-I. -I../../../lib  -I../../../proxy/api -I../../../proxy/api -I../../../lib 
-I./lib -I./fetcher -I./test -Dlinux -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 
-D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/include/libxml2 
-Wno-deprecated -std=c++11 -g -pipe -Wall -O3 -feliminate-unused-debug-symbols 
-fno-strict-aliasing -Werror -Wno-invalid-offsetof -mcx16 -MT combo_handler.lo 
-MD -MP -MF $depbase.Tpo -c -o combo_handler.lo combo_handler.cc &&\
mv -f $depbase.Tpo $depbase.Plo
depbase=`echo lib/DocNode.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../../libtool  --tag=CXX   --mode=compile ccache c++ -DHAVE_CONFIG_H 
-I. -I../../../lib  -I../../../proxy/api -I../../../proxy/api -I../../../lib 
-I./lib -I./fetcher -I./test -Dlinux -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 
-D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SSL_INTERN -I/usr/include/libxml2 
-Wno-deprecated -std=c++11 -g -pipe -Wall -O3 -feliminate-unused-debug-symbols 
-fno-strict-aliasing -Werror -Wno-invalid-offsetof -mcx16 -MT lib/DocNode.lo 
-MD -MP -MF $depbase.Tpo -c -o lib/DocNode.lo lib/DocNode.cc &&\
mv -f $depbase.Tpo $depbase.Plo
depbase=`echo lib/EsiParser.lo | sed 's|[^/]*$|.deps/&|;s|\.lo$||'`;\
/bin/sh ../../../libtool  --tag=CXX   --mode=compile ccache c++ -DHAVE_CONFIG_H 
-I. -I../../../lib  -I../../../proxy/api -I../../../proxy/api -I../../../lib 
-I./lib -I./fetcher -I./test -Dlinux -D_LARGEFILE64_SOURCE=1 
-D_COMPILE64BIT_SOURCE=1 -D_GNU_SOURCE -D_REENTRANT -D__STDC_LIMIT_MACROS=1 
-D__STDC_FORMAT_MACROS=1 -DOPENSSL_NO_SS

[jira] [Commented] (TS-3788) SNI callbacks stall after TS-3667 fix

[ASF subversion and git services (JIRA)]

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

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

Commit ed48c9053c80372413b631be7946b7d30728e9e3 in trafficserver's branch 
refs/heads/master from shinrich
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ed48c90 ]

TS-3788: SNI Callbacks stall after TS-3667 fix


> SNI callbacks stall after TS-3667 fix
> -
>
> Key: TS-3788
> URL: https://issues.apache.org/jira/browse/TS-3788
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.1.0
>
>
> Reported by [~oknet] and the main discussion is in the TS-3667.  Due to 
> changes in the fix for TS-3667, the EAGAIN would get checked before calling 
> SSL_accept.  If SSL_accept state machine needed to write data, it would never 
> get triggered and the handshake would stall.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3667) SSL Handhake read does not correctly handle EOF and error cases

[ASF subversion and git services (JIRA)]

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

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

Commit ed48c9053c80372413b631be7946b7d30728e9e3 in trafficserver's branch 
refs/heads/master from shinrich
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=ed48c90 ]

TS-3788: SNI Callbacks stall after TS-3667 fix


> SSL Handhake read does not correctly handle EOF and error cases
> ---
>
> Key: TS-3667
> URL: https://issues.apache.org/jira/browse/TS-3667
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Affects Versions: 5.2.0, 5.3.0
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 5.3.1, 6.0.0
>
> Attachments: ts-3667.diff
>
>
> Reported by [~esproul] and postwait.
> The return value of SSLNetVConnection::read_raw_data() is being ignored.  So 
> EOF and errors are not terminated, but rather spin until the inactivity 
> timeout is reached.  EAGAIN  is not being descheduled until more data is 
> available.
> This results in higher CPU utilization and hitting the SSL_error() function 
> much more than it needs to be hit.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3775) ASAN crash while running regression test Cache_vol

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda commented on TS-3775:
---

Hmm..is this commit against the correct jira - the fix seems unrelated to the 
problem mentioned on the jira or does the jira need a title change?

> ASAN crash while running regression test Cache_vol
> --
>
> Key: TS-3775
> URL: https://issues.apache.org/jira/browse/TS-3775
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Attachments: ts-3775.diff
>
>
> Seen while running master built with ASAN on FC 21.  I have a patch which 
> I'll attach and discuss in comment.
> {code}
> REGRESSION TEST Cache_vol started
> RPRINT Cache_vol: 1 128 Megabyte Volumes
> RPRINT Cache_vol: Not enough space for 10 volume
> RPRINT Cache_vol: Random Volumes after clearing the disks
> RPRINT Cache_vol: volume=1 scheme=http size=128
> RPRINT Cache_vol: Random Volumes without clearing the disks
> RPRINT Cache_vol: volume=1 scheme=rtsp size=128
> =
> ==4513==ERROR: AddressSanitizer: heap-use-after-free on address 
> 0x6048e9e0 at pc 0x989546 bp 0x7fffef2a59b0 sp 0x7fffef2a59a0
> READ of size 8 at 0x6048e9e0 thread T2 ([ET_NET 1])
> #0 0x989545 in cplist_update /home/shinrich/ats/iocore/cache/Cache.cc:2702
> #1 0x989545 in cplist_reconfigure() 
> /home/shinrich/ats/iocore/cache/Cache.cc:2846
> #2 0x9d1186 in execute_and_verify(RegressionTest*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:996
> #3 0x9d2229 in RegressionTest_Cache_vol(RegressionTest*, int, int*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:842
> #4 0x76cb55f1 in start_test /home/shinrich/ats/lib/ts/Regression.cc:78
> #5 0x76cb55f1 in RegressionTest::run_some() 
> /home/shinrich/ats/lib/ts/Regression.cc:126
> #6 0x76cb5b00 in RegressionTest::check_status() 
> /home/shinrich/ats/lib/ts/Regression.cc:141
> #7 0x5404fb in RegressionCont::mainEvent(int, Event*) 
> /home/shinrich/ats/proxy/Main.cc:1210
> #8 0xb6b771 in Continuation::handleEvent(int, void*) 
> /home/shinrich/ats/iocore/eventsystem/I_Continuation.h:146
> #9 0xb6b771 in EThread::process_event(Event*, int) 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:128
> #10 0xb6d3a6 in EThread::execute() 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:207
> #11 0xb69da1 in spawn_thread_internal 
> /home/shinrich/ats/iocore/eventsystem/Thread.cc:86
> #12 0x75e27529 in start_thread (/lib64/libpthread.so.0+0x7529)
> #13 0x7464922c in __clone (/lib64/libc.so.6+0x10022c)
> 0x6048e9e0 is located 16 bytes inside of 40-byte region 
> [0x6048e9d0,0x6048e9f8)
> freed by thread T2 ([ET_NET 1]) here:
> #0 0x76f5764f in operator delete(void*) (/lib64/libasan.so.1+0x5864f)
> #1 0x9c84ac in CacheDisk::delete_volume(int) 
> /home/shinrich/ats/iocore/cache/CacheDisk.cc:330
> #2 0x989455 in cplist_update /home/shinrich/ats/iocore/cache/Cache.cc:2684
> #3 0x989455 in cplist_reconfigure() 
> /home/shinrich/ats/iocore/cache/Cache.cc:2846
> #4 0x9d1186 in execute_and_verify(RegressionTest*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:996
> #5 0x9d2229 in RegressionTest_Cache_vol(RegressionTest*, int, int*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:842
> #6 0x76cb55f1 in start_test /home/shinrich/ats/lib/ts/Regression.cc:78
> #7 0x76cb55f1 in RegressionTest::run_some() 
> /home/shinrich/ats/lib/ts/Regression.cc:126
> #8 0x76cb5b00 in RegressionTest::check_status() 
> /home/shinrich/ats/lib/ts/Regression.cc:141
> #9 0x5404fb in RegressionCont::mainEvent(int, Event*) 
> /home/shinrich/ats/proxy/Main.cc:1210
> #10 0xb6b771 in Continuation::handleEvent(int, void*) 
> /home/shinrich/ats/iocore/eventsystem/I_Continuation.h:146
> #11 0xb6b771 in EThread::process_event(Event*, int) 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:128
> #12 0xb6d3a6 in EThread::execute() 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:207
> #13 0xb69da1 in spawn_thread_internal 
> /home/shinrich/ats/iocore/eventsystem/Thread.cc:86
> #14 0x75e27529 in start_thread (/lib64/libpthread.so.0+0x7529)
> previously allocated by thread T2 ([ET_NET 1]) here:
> #0 0x76f5714f in operator new(unsigned long) 
> (/lib64/libasan.so.1+0x5814f)
> #1 0x9c770d in CacheDisk::create_volume(int, long, int) 
> /home/shinrich/ats/iocore/cache/CacheDisk.cc:296
> #2 0x98347e in create_volume /home/shinrich/ats/iocore/cache/Cache.cc:3023
> #3 0x989b41 in cplist_reconfigure() 
> /home/shinrich/ats/iocore/cache/Cache.cc:2877
> 

[jira] [Comment Edited] (TS-3775) ASAN crash while running regression test Cache_vol

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda edited comment on TS-3775 at 7/22/15 8:22 PM:


Hmm..is this commit against the correct jira - the fix seems unrelated to the 
problem mentioned on the jira? or does the jira need a title change, perhaps?


was (Author: sudheerv):
Hmm..is this commit against the correct jira - the fix seems unrelated to the 
problem mentioned on the jira or does the jira need a title change?

> ASAN crash while running regression test Cache_vol
> --
>
> Key: TS-3775
> URL: https://issues.apache.org/jira/browse/TS-3775
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Attachments: ts-3775.diff
>
>
> Seen while running master built with ASAN on FC 21.  I have a patch which 
> I'll attach and discuss in comment.
> {code}
> REGRESSION TEST Cache_vol started
> RPRINT Cache_vol: 1 128 Megabyte Volumes
> RPRINT Cache_vol: Not enough space for 10 volume
> RPRINT Cache_vol: Random Volumes after clearing the disks
> RPRINT Cache_vol: volume=1 scheme=http size=128
> RPRINT Cache_vol: Random Volumes without clearing the disks
> RPRINT Cache_vol: volume=1 scheme=rtsp size=128
> =
> ==4513==ERROR: AddressSanitizer: heap-use-after-free on address 
> 0x6048e9e0 at pc 0x989546 bp 0x7fffef2a59b0 sp 0x7fffef2a59a0
> READ of size 8 at 0x6048e9e0 thread T2 ([ET_NET 1])
> #0 0x989545 in cplist_update /home/shinrich/ats/iocore/cache/Cache.cc:2702
> #1 0x989545 in cplist_reconfigure() 
> /home/shinrich/ats/iocore/cache/Cache.cc:2846
> #2 0x9d1186 in execute_and_verify(RegressionTest*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:996
> #3 0x9d2229 in RegressionTest_Cache_vol(RegressionTest*, int, int*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:842
> #4 0x76cb55f1 in start_test /home/shinrich/ats/lib/ts/Regression.cc:78
> #5 0x76cb55f1 in RegressionTest::run_some() 
> /home/shinrich/ats/lib/ts/Regression.cc:126
> #6 0x76cb5b00 in RegressionTest::check_status() 
> /home/shinrich/ats/lib/ts/Regression.cc:141
> #7 0x5404fb in RegressionCont::mainEvent(int, Event*) 
> /home/shinrich/ats/proxy/Main.cc:1210
> #8 0xb6b771 in Continuation::handleEvent(int, void*) 
> /home/shinrich/ats/iocore/eventsystem/I_Continuation.h:146
> #9 0xb6b771 in EThread::process_event(Event*, int) 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:128
> #10 0xb6d3a6 in EThread::execute() 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:207
> #11 0xb69da1 in spawn_thread_internal 
> /home/shinrich/ats/iocore/eventsystem/Thread.cc:86
> #12 0x75e27529 in start_thread (/lib64/libpthread.so.0+0x7529)
> #13 0x7464922c in __clone (/lib64/libc.so.6+0x10022c)
> 0x6048e9e0 is located 16 bytes inside of 40-byte region 
> [0x6048e9d0,0x6048e9f8)
> freed by thread T2 ([ET_NET 1]) here:
> #0 0x76f5764f in operator delete(void*) (/lib64/libasan.so.1+0x5864f)
> #1 0x9c84ac in CacheDisk::delete_volume(int) 
> /home/shinrich/ats/iocore/cache/CacheDisk.cc:330
> #2 0x989455 in cplist_update /home/shinrich/ats/iocore/cache/Cache.cc:2684
> #3 0x989455 in cplist_reconfigure() 
> /home/shinrich/ats/iocore/cache/Cache.cc:2846
> #4 0x9d1186 in execute_and_verify(RegressionTest*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:996
> #5 0x9d2229 in RegressionTest_Cache_vol(RegressionTest*, int, int*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:842
> #6 0x76cb55f1 in start_test /home/shinrich/ats/lib/ts/Regression.cc:78
> #7 0x76cb55f1 in RegressionTest::run_some() 
> /home/shinrich/ats/lib/ts/Regression.cc:126
> #8 0x76cb5b00 in RegressionTest::check_status() 
> /home/shinrich/ats/lib/ts/Regression.cc:141
> #9 0x5404fb in RegressionCont::mainEvent(int, Event*) 
> /home/shinrich/ats/proxy/Main.cc:1210
> #10 0xb6b771 in Continuation::handleEvent(int, void*) 
> /home/shinrich/ats/iocore/eventsystem/I_Continuation.h:146
> #11 0xb6b771 in EThread::process_event(Event*, int) 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:128
> #12 0xb6d3a6 in EThread::execute() 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:207
> #13 0xb69da1 in spawn_thread_internal 
> /home/shinrich/ats/iocore/eventsystem/Thread.cc:86
> #14 0x75e27529 in start_thread (/lib64/libpthread.so.0+0x7529)
> previously allocated by thread T2 ([ET_NET 1]) here:
> #0 0x76f5714f in operator new(unsigned long) 
> (/lib64/libasan.so.1+0x5814f)
> #1 0x9c770d in CacheDisk::create_volume(int, long, int

[jira] [Commented] (TS-3790) action=tunnel in ssl_multicert.config will cause crash

[ASF subversion and git services (JIRA)]

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

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

Commit 0ca8bff4c52ac066fbc74f8061338b9a8d1763fc in trafficserver's branch 
refs/heads/master from shinrich
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=0ca8bff ]

TS-3790: action=tunnel attribute will cause crash.


> action=tunnel in ssl_multicert.config will cause crash
> --
>
> Key: TS-3790
> URL: https://issues.apache.org/jira/browse/TS-3790
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Attachments: ts-3790.diff
>
>
> Enabled an old line in my ssl_multicert.config and accidentally tested the 
> action=tunnel feature.  It caused the traffic_server process to crash.  The 
> code was assuming that a handShakeBuffer must be present if we are deciding 
> to do a blind tunnel, but that is only the case if the decision is made in 
> the SNI callback.  I'm going to attach a patch that fixes the problem.
> Example line that will trigger the issue.  Packets addressed to 1.2.3.4 will 
> try to convert to blind tunnel before any SSL handshake processing is 
> attempted.
> {code}
> dest_ip=1.2.3.4 action=tunnel ssl_cert_name=servercert.pem 
> ssl_key_name=privkey.pem
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Build failed in Jenkins: clang-format #46

[jenkins]

See 

Changes:

[shinrich] TS-3775:  Adjust the mutex assignment for SpdyClientSession to avoid 
unlocked read vio.

--
[...truncated 4254 lines...]
+ clang-format -i src/proxy/UserNameCacheTest.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/ICP.h
src/proxy/ICP.h
+ clang-format -i src/proxy/ICP.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/ProxyClientSession.h
src/proxy/ProxyClientSession.h
+ clang-format -i src/proxy/ProxyClientSession.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/CacheControl.h
src/proxy/CacheControl.h
+ clang-format -i src/proxy/CacheControl.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/InkAPITestTool.cc
src/proxy/InkAPITestTool.cc
+ clang-format -i src/proxy/InkAPITestTool.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/ControlBase.cc
src/proxy/ControlBase.cc
+ clang-format -i src/proxy/ControlBase.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2ClientSession.cc
src/proxy/http2/Http2ClientSession.cc
+ clang-format -i src/proxy/http2/Http2ClientSession.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2ConnectionState.h
src/proxy/http2/Http2ConnectionState.h
+ clang-format -i src/proxy/http2/Http2ConnectionState.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/test_Huffmancode.cc
src/proxy/http2/test_Huffmancode.cc
+ clang-format -i src/proxy/http2/test_Huffmancode.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2SessionAccept.h
src/proxy/http2/Http2SessionAccept.h
+ clang-format -i src/proxy/http2/Http2SessionAccept.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HuffmanCodec.h
src/proxy/http2/HuffmanCodec.h
+ clang-format -i src/proxy/http2/HuffmanCodec.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2ConnectionState.cc
src/proxy/http2/Http2ConnectionState.cc
+ clang-format -i src/proxy/http2/Http2ConnectionState.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HTTP2.cc
src/proxy/http2/HTTP2.cc
+ clang-format -i src/proxy/http2/HTTP2.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2ClientSession.h
src/proxy/http2/Http2ClientSession.h
+ clang-format -i src/proxy/http2/Http2ClientSession.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HPACK.h
src/proxy/http2/HPACK.h
+ clang-format -i src/proxy/http2/HPACK.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HTTP2.h
src/proxy/http2/HTTP2.h
+ clang-format -i src/proxy/http2/HTTP2.h
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HuffmanCodec.cc
src/proxy/http2/HuffmanCodec.cc
+ clang-format -i src/proxy/http2/HuffmanCodec.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/Http2SessionAccept.cc
src/proxy/http2/Http2SessionAccept.cc
+ clang-format -i src/proxy/http2/Http2SessionAccept.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/http2/HPACK.cc
src/proxy/http2/HPACK.cc
+ clang-format -i src/proxy/http2/HPACK.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/Main.cc
src/proxy/Main.cc
+ clang-format -i src/proxy/Main.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/UDPAPIClientTest.cc
src/proxy/UDPAPIClientTest.cc
+ clang-format -i src/proxy/UDPAPIClientTest.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/Plugin.cc
src/proxy/Plugin.cc
+ clang-format -i src/proxy/Plugin.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/tsconfig`'
+ echo src/proxy/TestClock.cc
src/proxy/TestClock.cc
+ clang-format -i src/proxy/TestClock.cc
+ for f in '`find src -iname \*.[ch] -o -iname \*.cc | fgrep -v -e lib/luajit 
-e lib/t

[jira] [Commented] (TS-3775) ASAN crash while running regression test Cache_vol

[ASF subversion and git services (JIRA)]

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

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

Commit 6f66b7a18234a93e810d8ef2ce23144b9b3446f4 in trafficserver's branch 
refs/heads/master from shinrich
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6f66b7a ]

TS-3775:  Adjust the mutex assignment for SpdyClientSession to avoid unlocked 
read vio.


> ASAN crash while running regression test Cache_vol
> --
>
> Key: TS-3775
> URL: https://issues.apache.org/jira/browse/TS-3775
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Attachments: ts-3775.diff
>
>
> Seen while running master built with ASAN on FC 21.  I have a patch which 
> I'll attach and discuss in comment.
> {code}
> REGRESSION TEST Cache_vol started
> RPRINT Cache_vol: 1 128 Megabyte Volumes
> RPRINT Cache_vol: Not enough space for 10 volume
> RPRINT Cache_vol: Random Volumes after clearing the disks
> RPRINT Cache_vol: volume=1 scheme=http size=128
> RPRINT Cache_vol: Random Volumes without clearing the disks
> RPRINT Cache_vol: volume=1 scheme=rtsp size=128
> =
> ==4513==ERROR: AddressSanitizer: heap-use-after-free on address 
> 0x6048e9e0 at pc 0x989546 bp 0x7fffef2a59b0 sp 0x7fffef2a59a0
> READ of size 8 at 0x6048e9e0 thread T2 ([ET_NET 1])
> #0 0x989545 in cplist_update /home/shinrich/ats/iocore/cache/Cache.cc:2702
> #1 0x989545 in cplist_reconfigure() 
> /home/shinrich/ats/iocore/cache/Cache.cc:2846
> #2 0x9d1186 in execute_and_verify(RegressionTest*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:996
> #3 0x9d2229 in RegressionTest_Cache_vol(RegressionTest*, int, int*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:842
> #4 0x76cb55f1 in start_test /home/shinrich/ats/lib/ts/Regression.cc:78
> #5 0x76cb55f1 in RegressionTest::run_some() 
> /home/shinrich/ats/lib/ts/Regression.cc:126
> #6 0x76cb5b00 in RegressionTest::check_status() 
> /home/shinrich/ats/lib/ts/Regression.cc:141
> #7 0x5404fb in RegressionCont::mainEvent(int, Event*) 
> /home/shinrich/ats/proxy/Main.cc:1210
> #8 0xb6b771 in Continuation::handleEvent(int, void*) 
> /home/shinrich/ats/iocore/eventsystem/I_Continuation.h:146
> #9 0xb6b771 in EThread::process_event(Event*, int) 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:128
> #10 0xb6d3a6 in EThread::execute() 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:207
> #11 0xb69da1 in spawn_thread_internal 
> /home/shinrich/ats/iocore/eventsystem/Thread.cc:86
> #12 0x75e27529 in start_thread (/lib64/libpthread.so.0+0x7529)
> #13 0x7464922c in __clone (/lib64/libc.so.6+0x10022c)
> 0x6048e9e0 is located 16 bytes inside of 40-byte region 
> [0x6048e9d0,0x6048e9f8)
> freed by thread T2 ([ET_NET 1]) here:
> #0 0x76f5764f in operator delete(void*) (/lib64/libasan.so.1+0x5864f)
> #1 0x9c84ac in CacheDisk::delete_volume(int) 
> /home/shinrich/ats/iocore/cache/CacheDisk.cc:330
> #2 0x989455 in cplist_update /home/shinrich/ats/iocore/cache/Cache.cc:2684
> #3 0x989455 in cplist_reconfigure() 
> /home/shinrich/ats/iocore/cache/Cache.cc:2846
> #4 0x9d1186 in execute_and_verify(RegressionTest*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:996
> #5 0x9d2229 in RegressionTest_Cache_vol(RegressionTest*, int, int*) 
> /home/shinrich/ats/iocore/cache/CacheHosting.cc:842
> #6 0x76cb55f1 in start_test /home/shinrich/ats/lib/ts/Regression.cc:78
> #7 0x76cb55f1 in RegressionTest::run_some() 
> /home/shinrich/ats/lib/ts/Regression.cc:126
> #8 0x76cb5b00 in RegressionTest::check_status() 
> /home/shinrich/ats/lib/ts/Regression.cc:141
> #9 0x5404fb in RegressionCont::mainEvent(int, Event*) 
> /home/shinrich/ats/proxy/Main.cc:1210
> #10 0xb6b771 in Continuation::handleEvent(int, void*) 
> /home/shinrich/ats/iocore/eventsystem/I_Continuation.h:146
> #11 0xb6b771 in EThread::process_event(Event*, int) 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:128
> #12 0xb6d3a6 in EThread::execute() 
> /home/shinrich/ats/iocore/eventsystem/UnixEThread.cc:207
> #13 0xb69da1 in spawn_thread_internal 
> /home/shinrich/ats/iocore/eventsystem/Thread.cc:86
> #14 0x75e27529 in start_thread (/lib64/libpthread.so.0+0x7529)
> previously allocated by thread T2 ([ET_NET 1]) here:
> #0 0x76f5714f in operator new(unsigned long) 
> (/lib64/libasan.so.1+0x5814f)
> #1 0x9c770d in CacheDisk::create_volume(int, long, int) 
> /home/shinrich/ats/iocore/cache/CacheDisk.cc:296
> #2 0x98347e in crea

[jira] [Commented] (TS-3788) SNI callbacks stall after TS-3667 fix

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-3788:


Was able to reproduce [~oknet]'s issue and uncovered a couple other issues 
along the way.  Will get the commit we discussed on the other bug committed. 

Agree on the backport.

> SNI callbacks stall after TS-3667 fix
> -
>
> Key: TS-3788
> URL: https://issues.apache.org/jira/browse/TS-3788
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.1.0
>
>
> Reported by [~oknet] and the main discussion is in the TS-3667.  Due to 
> changes in the fix for TS-3667, the EAGAIN would get checked before calling 
> SSL_accept.  If SSL_accept state machine needed to write data, it would never 
> get triggered and the handshake would stall.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3767) More unbounded retries within read-while-writer breaking loop detection.

[Sudheer Vinukonda (JIRA)]

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

Sudheer Vinukonda updated TS-3767:
--
Backport to Version: 6.0.0

> More unbounded retries within read-while-writer breaking loop detection.
> 
>
> Key: TS-3767
> URL: https://issues.apache.org/jira/browse/TS-3767
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
>  Labels: A
> Fix For: 6.1.0
>
>
> [~zwoop] noticed the loop detection (request to self) fails with default 
> settings, when read-while-writer functionality is enabled. Upon further 
> investigation, this seems to be caused by more cases of unbounded retries 
> within read-while-writer (similar to TS-3622), which prevent reaching the 
> loop detection point (currently, done after the cache lookup state).
> TS-3622 added a bound for read-while-writer in the case, where the writer 
> lock is available, but, the first fragment is not downloaded yet, but, there 
> are more cases which cause similar issues. 
> Discussing with [~zwoop], we think we should add bounds in all such cases 
> with configurable timer (duration) and configurable max number of retries.
> Also, refer TS-3768 for a future improvement on this.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-469) A PUT request should invalidate a previously cached object with the same URI

[John Paul Vasicek (JIRA)]

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

John Paul Vasicek updated TS-469:
-
Attachment: APIMAN-1273.patch

This works on ATS 4x

> A PUT request should invalidate a previously cached object with the same URI
> 
>
> Key: TS-469
> URL: https://issues.apache.org/jira/browse/TS-469
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP
>Affects Versions: 2.1.6
>Reporter: Leif Hedstrom
>  Labels: CoAdvisor
> Fix For: sometime
>
> Attachments: APIMAN-1273.patch
>
>
> If the client first fetches an object with GET, and TS caches it, a 
> subsequent PUT request for the same URL should invalidate the cached object.
> Update: This is a problem with PUT/POST when the response from the origin is 
> a 201, and there is a Location: header. We then must also invalidate any 
> cached object for the URL which the Location header refers to
> (Originally discovered with Coadvisor).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3790) action=tunnel in ssl_multicert.config will cause crash

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs updated TS-3790:
---
Attachment: ts-3790.diff

TS-3790.diff is the code change.  Most of the lines are just indentation 
change.  Folding the tests so only one case checks handShakeBuffer.

> action=tunnel in ssl_multicert.config will cause crash
> --
>
> Key: TS-3790
> URL: https://issues.apache.org/jira/browse/TS-3790
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Attachments: ts-3790.diff
>
>
> Enabled an old line in my ssl_multicert.config and accidentally tested the 
> action=tunnel feature.  It caused the traffic_server process to crash.  The 
> code was assuming that a handShakeBuffer must be present if we are deciding 
> to do a blind tunnel, but that is only the case if the decision is made in 
> the SNI callback.  I'm going to attach a patch that fixes the problem.
> Example line that will trigger the issue.  Packets addressed to 1.2.3.4 will 
> try to convert to blind tunnel before any SSL handshake processing is 
> attempted.
> {code}
> dest_ip=1.2.3.4 action=tunnel ssl_cert_name=servercert.pem 
> ssl_key_name=privkey.pem
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-3790) action=tunnel in ssl_multicert.config will cause crash

[Susan Hinrichs (JIRA)]

Susan Hinrichs created TS-3790:
--

 Summary: action=tunnel in ssl_multicert.config will cause crash
 Key: TS-3790
 URL: https://issues.apache.org/jira/browse/TS-3790
 Project: Traffic Server
  Issue Type: Bug
  Components: SSL
Reporter: Susan Hinrichs


Enabled an old line in my ssl_multicert.config and accidentally tested the 
action=tunnel feature.  It caused the traffic_server process to crash.  The 
code was assuming that a handShakeBuffer must be present if we are deciding to 
do a blind tunnel, but that is only the case if the decision is made in the SNI 
callback.  I'm going to attach a patch that fixes the problem.

Example line that will trigger the issue.  Packets addressed to 1.2.3.4 will 
try to convert to blind tunnel before any SSL handshake processing is attempted.

{code}
dest_ip=1.2.3.4 action=tunnel ssl_cert_name=servercert.pem 
ssl_key_name=privkey.pem
{code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-3790) action=tunnel in ssl_multicert.config will cause crash

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs reassigned TS-3790:
--

Assignee: Susan Hinrichs

> action=tunnel in ssl_multicert.config will cause crash
> --
>
> Key: TS-3790
> URL: https://issues.apache.org/jira/browse/TS-3790
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>
> Enabled an old line in my ssl_multicert.config and accidentally tested the 
> action=tunnel feature.  It caused the traffic_server process to crash.  The 
> code was assuming that a handShakeBuffer must be present if we are deciding 
> to do a blind tunnel, but that is only the case if the decision is made in 
> the SNI callback.  I'm going to attach a patch that fixes the problem.
> Example line that will trigger the issue.  Packets addressed to 1.2.3.4 will 
> try to convert to blind tunnel before any SSL handshake processing is 
> attempted.
> {code}
> dest_ip=1.2.3.4 action=tunnel ssl_cert_name=servercert.pem 
> ssl_key_name=privkey.pem
> {code}



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3780) Logs_xml: add logging field for incoming (interface) ip.

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3780:


Github user ericcarlschwartz commented on the pull request:

https://github.com/apache/trafficserver/pull/258#issuecomment-123753341
  
Sounds good to me just wanted to make sure they both get closed out!


> Logs_xml: add logging field for incoming (interface) ip.
> 
>
> Key: TS-3780
> URL: https://issues.apache.org/jira/browse/TS-3780
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Core, Logging
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>  Labels: review
> Fix For: 6.1.0
>
>
> It would be great if in a logs_xml config we could have it log the incoming 
> (interface) ip.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Build failed in Jenkins: tsqa-master #714

[jenkins]

See 

Changes:

[Leif Hedstrom] Update license headers

--
[...truncated 509 lines...]
INFO 2015-07-22 14:52:09,617 - sending data back to the client
INFO 2015-07-22 14:52:12,020 - sending data back to the client
INFO 2015-07-22 14:52:14,424 - sending data back to the client
INFO 2015-07-22 14:52:18,428 - sending data back to the client
ok
test_chunked_keepalive_server (test_chunked.TestChunked) ... INFO 2015-07-22 
14:52:22,433 - sending data back to the client
INFO 2015-07-22 14:52:25,438 - sending data back to the client
ok
Test that the origin does in fact support keepalive ... INFO 2015-07-22 
14:52:26,443 - sending data back to the client
INFO 2015-07-22 14:52:29,448 - sending data back to the client
INFO 2015-07-22 14:52:30,456 - sending data back to the client
INFO 2015-07-22 14:52:32,457 - Client disconnected
INFO 2015-07-22 14:52:32,859 - sending data back to the client
INFO 2015-07-22 14:52:33,262 - sending data back to the client
INFO 2015-07-22 14:52:35,263 - Client disconnected
INFO 2015-07-22 14:52:37,267 - sending data back to the client
ok
INFO 2015-07-22 14:52:39,277 - Client disconnected
INFO 2015-07-22 14:52:39,464 - Environment prefix is /tmp/tsqa.env.j85rwp
INFO 2015-07-22 14:52:41,271 - Client disconnected
Verify that we get 502s from an origin which just did a bind ... ok
Verify that we get 200s from origins that delayed_accept_after_connect ... ok
Verify that we get 504s from origins that die_on_connect ... ok
Verify that we get 502s from origins that bind + listen ... ok
Verify that we get 504s from origins that return a partial_response ... FAIL
Verify that we get 200s from origins that reset_after_accept ... FAIL
INFO 2015-07-22 14:52:49,773 - Environment prefix is /tmp/tsqa.env.vf2AAJ
test_default_404 (test_example.TestBootstrap) ... ok
Test that traffic_line works, and verify that the values for proxy.config ... ok
INFO 2015-07-22 14:53:21,668 - Starting build 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-07-22 14:55:43,989 - Build completed 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-07-22 14:55:44,057 - Environment prefix is /tmp/tsqa.env.akUrsm
test_spdy (test_example.TestConfigureFlags) ... ok
INFO 2015-07-22 14:55:47,576 - Environment prefix is /tmp/tsqa.env.elxj0c
test_basic_proxy (test_example.TestDynamicHTTPEndpointCase) ... 127.0.0.1 - - 
[22/Jul/2015 14:55:50] "GET /test HTTP/1.1" 404 0
ok
INFO 2015-07-22 14:55:51,087 - Environment prefix is /tmp/tsqa.env.brjkU1
test_logs_exist (test_example.TestLogRefCounting) ... 127.0.0.1 - - 
[22/Jul/2015 14:55:54] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 14:55:54] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 14:55:54] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 14:55:54] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 14:55:54] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 14:55:54] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 14:55:54] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 14:55:54] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 14:55:54] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 14:55:54] "GET / HTTP/1.1" 404 0
FAIL
INFO 2015-07-22 14:56:04,591 - Environment prefix is /tmp/tsqa.env.EbkRT8
test_logs_exist (test_example.TestLogs) ... FAIL
SKIP: Skip the entire class
INFO 2015-07-22 14:56:18,054 - Environment prefix is /tmp/tsqa.env.VXqkhF
test_basic_intercept (test_example.TestServerIntercept) ... 127.0.0.1 - - 
[22/Jul/2015 14:56:21] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 14:56:21] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 14:56:21] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 14:56:21] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 14:56:21] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 14:56:21] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 14:56:21] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 14:56:21] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 14:56:21] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 14:56:21] "GET / HTTP/1.1" 200 5
ok
INFO 2015-07-22 14:56:21,510 - Environment prefix is /tmp/tsqa.env.vTCKMT
test_lookup_timeout (test_hostdb.TestHostDBFailedDNS) ... ok
INFO 2015-07-22 14:56:26,948 - Environment prefix is /tmp/tsqa.env.iztHT9
Test basic fnctionality of hosts files ... ok
Test that changes to hosts file get loaded within host_file.interval ... ok
INFO 2015-07-22 14:56:36,422 - Environment prefix is /tmp/tsqa.env.KquAHe
SKIP: 
 >> begin captured logging << 
root: INFO: Environment prefix 

[jira] [Commented] (TS-3788) SNI callbacks stall after TS-3667 fix

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3788:
---

This probably needs a back port to both 5.3.2 and 6.0.0.

> SNI callbacks stall after TS-3667 fix
> -
>
> Key: TS-3788
> URL: https://issues.apache.org/jira/browse/TS-3788
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.1.0
>
>
> Reported by [~oknet] and the main discussion is in the TS-3667.  Due to 
> changes in the fix for TS-3667, the EAGAIN would get checked before calling 
> SSL_accept.  If SSL_accept state machine needed to write data, it would never 
> get triggered and the handshake would stall.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-3789) If HTTP/2 is negotiated, TLS compression must be disabled

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-3789:
-

 Summary: If HTTP/2 is negotiated, TLS compression must be disabled
 Key: TS-3789
 URL: https://issues.apache.org/jira/browse/TS-3789
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP/2
Reporter: Leif Hedstrom


Per https://tools.ietf.org/html/rfc7540#section-9.2. Couple of options:

1) Make these overridable / configurable per protocol.

2) Basically make proxy.config.ssl.compression=0 always if HTTP/2 is enabled.




--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Build failed in Jenkins: tsqa-master #713

[jenkins]

See 

Changes:

[Leif Hedstrom] TS-3786 Missed one clang-format case :)

--
[...truncated 508 lines...]
INFO 2015-07-22 14:39:45,268 - sending data back to the client
INFO 2015-07-22 14:39:47,671 - sending data back to the client
INFO 2015-07-22 14:39:50,075 - sending data back to the client
INFO 2015-07-22 14:39:54,078 - sending data back to the client
ok
test_chunked_keepalive_server (test_chunked.TestChunked) ... INFO 2015-07-22 
14:39:58,082 - sending data back to the client
INFO 2015-07-22 14:40:01,087 - sending data back to the client
ok
Test that the origin does in fact support keepalive ... INFO 2015-07-22 
14:40:02,092 - sending data back to the client
INFO 2015-07-22 14:40:05,097 - sending data back to the client
INFO 2015-07-22 14:40:06,100 - sending data back to the client
INFO 2015-07-22 14:40:08,101 - Client disconnected
INFO 2015-07-22 14:40:08,503 - sending data back to the client
INFO 2015-07-22 14:40:08,906 - sending data back to the client
INFO 2015-07-22 14:40:10,907 - Client disconnected
INFO 2015-07-22 14:40:12,911 - sending data back to the client
ok
INFO 2015-07-22 14:40:14,921 - Client disconnected
INFO 2015-07-22 14:40:15,111 - Environment prefix is /tmp/tsqa.env.auDiPA
INFO 2015-07-22 14:40:16,915 - Client disconnected
Verify that we get 502s from an origin which just did a bind ... ok
Verify that we get 200s from origins that delayed_accept_after_connect ... ok
Verify that we get 504s from origins that die_on_connect ... ok
Verify that we get 502s from origins that bind + listen ... ok
Verify that we get 504s from origins that return a partial_response ... FAIL
Verify that we get 200s from origins that reset_after_accept ... FAIL
INFO 2015-07-22 14:40:25,406 - Environment prefix is /tmp/tsqa.env.DgIZdt
test_default_404 (test_example.TestBootstrap) ... ok
Test that traffic_line works, and verify that the values for proxy.config ... ok
INFO 2015-07-22 14:40:55,178 - Starting build 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-07-22 14:41:47,227 - Build completed 
(1b6c9541459e058351cd39ec55dcb772): configure {'enable-spdy': None, 
'enable-ccache': None, 'enable-experimental-plugins': None, 
'enable-example-plugins': None, 'enable-test-tools': None, 
'disable-dependency-tracking': None}
INFO 2015-07-22 14:41:47,291 - Environment prefix is /tmp/tsqa.env.JoKm3j
test_spdy (test_example.TestConfigureFlags) ... ok
INFO 2015-07-22 14:41:50,698 - Environment prefix is /tmp/tsqa.env.9ZITak
test_basic_proxy (test_example.TestDynamicHTTPEndpointCase) ... 127.0.0.1 - - 
[22/Jul/2015 14:41:53] "GET /test HTTP/1.1" 404 0
ok
INFO 2015-07-22 14:41:54,104 - Environment prefix is /tmp/tsqa.env.hVk45e
test_logs_exist (test_example.TestLogRefCounting) ... 127.0.0.1 - - 
[22/Jul/2015 14:41:57] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 14:41:57] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 14:41:57] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 14:41:57] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 14:41:57] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 14:41:57] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 14:41:57] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 14:41:57] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 14:41:57] "GET / HTTP/1.1" 404 0
127.0.0.1 - - [22/Jul/2015 14:41:57] "GET / HTTP/1.1" 404 0
FAIL
INFO 2015-07-22 14:42:07,577 - Environment prefix is /tmp/tsqa.env.J7W224
test_logs_exist (test_example.TestLogs) ... FAIL
SKIP: Skip the entire class
INFO 2015-07-22 14:42:21,017 - Environment prefix is /tmp/tsqa.env.pB88nL
test_basic_intercept (test_example.TestServerIntercept) ... 127.0.0.1 - - 
[22/Jul/2015 14:42:24] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 14:42:24] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 14:42:24] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 14:42:24] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 14:42:24] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 14:42:24] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 14:42:24] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 14:42:24] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 14:42:24] "GET / HTTP/1.1" 200 5
127.0.0.1 - - [22/Jul/2015 14:42:24] "GET / HTTP/1.1" 200 5
ok
INFO 2015-07-22 14:42:24,461 - Environment prefix is /tmp/tsqa.env.zcfWo0
test_lookup_timeout (test_hostdb.TestHostDBFailedDNS) ... ok
INFO 2015-07-22 14:42:29,884 - Environment prefix is /tmp/tsqa.env.rIhDRr
Test basic fnctionality of hosts files ... ok
Test that changes to hosts file get loaded within host_file.interval ... ok
INFO 2015-07-22 14:42:41,344 - Environment prefix is /tmp/tsqa.env.jC78F0
SKIP: 
 >> begin captured logging << 
root: INFO: En

[jira] [Updated] (TS-3788) SNI callbacks stall after TS-3667 fix

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3788:
--
Fix Version/s: 6.1.0

> SNI callbacks stall after TS-3667 fix
> -
>
> Key: TS-3788
> URL: https://issues.apache.org/jira/browse/TS-3788
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.1.0
>
>
> Reported by [~oknet] and the main discussion is in the TS-3667.  Due to 
> changes in the fix for TS-3667, the EAGAIN would get checked before calling 
> SSL_accept.  If SSL_accept state machine needed to write data, it would never 
> get triggered and the handshake would stall.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3787) Don't allow blacklisted HTTP/2 ciphers to use HTTP/2

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3787:
---

https://tools.ietf.org/html/rfc7540#section-9.2

> Don't allow blacklisted HTTP/2 ciphers to use HTTP/2
> 
>
> Key: TS-3787
> URL: https://issues.apache.org/jira/browse/TS-3787
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Bryan Call
>  Labels: yahoo
> Fix For: 6.1.0
>
>
> Look at the selected cipher and if it is on the blacklist then don't allow 
> the client to use HTTP/2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3667) SSL Handhake read does not correctly handle EOF and error cases

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs commented on TS-3667:


Filed TS-3784 to track the locking debug assert.

> SSL Handhake read does not correctly handle EOF and error cases
> ---
>
> Key: TS-3667
> URL: https://issues.apache.org/jira/browse/TS-3667
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Affects Versions: 5.2.0, 5.3.0
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 5.3.1, 6.0.0
>
> Attachments: ts-3667.diff
>
>
> Reported by [~esproul] and postwait.
> The return value of SSLNetVConnection::read_raw_data() is being ignored.  So 
> EOF and errors are not terminated, but rather spin until the inactivity 
> timeout is reached.  EAGAIN  is not being descheduled until more data is 
> available.
> This results in higher CPU utilization and hitting the SSL_error() function 
> much more than it needs to be hit.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Closed] (TS-3667) SSL Handhake read does not correctly handle EOF and error cases

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs closed TS-3667.
--
Resolution: Fixed

Opened a new bug TS-3788 to track the problem noted by [~oknet]

> SSL Handhake read does not correctly handle EOF and error cases
> ---
>
> Key: TS-3667
> URL: https://issues.apache.org/jira/browse/TS-3667
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Affects Versions: 5.2.0, 5.3.0
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 6.0.0, 5.3.1
>
> Attachments: ts-3667.diff
>
>
> Reported by [~esproul] and postwait.
> The return value of SSLNetVConnection::read_raw_data() is being ignored.  So 
> EOF and errors are not terminated, but rather spin until the inactivity 
> timeout is reached.  EAGAIN  is not being descheduled until more data is 
> available.
> This results in higher CPU utilization and hitting the SSL_error() function 
> much more than it needs to be hit.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Assigned] (TS-3788) SNI callbacks stall after TS-3667 fix

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs reassigned TS-3788:
--

Assignee: Susan Hinrichs

> SNI callbacks stall after TS-3667 fix
> -
>
> Key: TS-3788
> URL: https://issues.apache.org/jira/browse/TS-3788
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
>
> Reported by [~oknet] and the main discussion is in the TS-3667.  Due to 
> changes in the fix for TS-3667, the EAGAIN would get checked before calling 
> SSL_accept.  If SSL_accept state machine needed to write data, it would never 
> get triggered and the handshake would stall.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (TS-3788) SNI callbacks stall after TS-3667 fix

[Susan Hinrichs (JIRA)]

Susan Hinrichs created TS-3788:
--

 Summary: SNI callbacks stall after TS-3667 fix
 Key: TS-3788
 URL: https://issues.apache.org/jira/browse/TS-3788
 Project: Traffic Server
  Issue Type: Bug
  Components: SSL
Reporter: Susan Hinrichs


Reported by [~oknet] and the main discussion is in the TS-3667.  Due to changes 
in the fix for TS-3667, the EAGAIN would get checked before calling SSL_accept. 
 If SSL_accept state machine needed to write data, it would never get triggered 
and the handshake would stall.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Jenkins build is back to normal : clang-format #43

[jenkins]

See 

[jira] [Commented] (TS-3786) Use a consensus algorithm to elect the cluster master

[ASF subversion and git services (JIRA)]

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

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

Commit 6448a82b477745407d5efc1c982c9d4f5e8f2179 in trafficserver's branch 
refs/heads/master from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=6448a82 ]

TS-3786 Missed one clang-format case :)


> Use a consensus algorithm to elect the cluster master
> -
>
> Key: TS-3786
> URL: https://issues.apache.org/jira/browse/TS-3786
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Manager
>Reporter: John Plevyak
>Assignee: John Plevyak
> Fix For: 6.1.0
>
>
> We should use a consensus algorithm to elect the cluster master and to update 
> the configurations so that there is no single point of failure and machines 
> entering or restarting can be brought to a consistent state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TS-3782) Add tests for HTTP/2 in TSQA

[Masaori Koshiba (JIRA)]

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

Masaori Koshiba edited comment on TS-3782 at 7/22/15 10:15 AM:
---

Basic normal scenario tests with hyper.
This test requires hyper, openssl-1.0.1+, python-2.7.9+ or 3.4+.


was (Author: masaori):
Basic normal scenario tests with hyper.
This test requires hyper, openssl-1.0.2+, python-2.7.9+ or 3.4+.

> Add tests for HTTP/2 in TSQA
> 
>
> Key: TS-3782
> URL: https://issues.apache.org/jira/browse/TS-3782
> Project: Traffic Server
>  Issue Type: Test
>  Components: CI, HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Thomas Jackson
>  Labels: review
> Fix For: 6.1.0
>
> Attachments: normal_scenario_tests_001.patch
>
>
> Add tests for HTTP/2 in TSQA. IMO, it is better to add two types of tests for 
> HTTP/2 below.
> 1. Normal Scenario Tests
>   - Do HTTP requests with [hyper|https://github.com/lukasa/hyper] or other 
> HTTP/2 client.
> 2. Exceptional Scenario Tests
>   - [h2spec|https://github.com/summerwind/h2spec] looks good test tool for 
> edge cases of HTTP/2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3753) High CPU iowait with null-transform on a content from the cache.

[Pavel Vazharov (JIRA)]

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

Pavel Vazharov commented on TS-3753:


We did two types of tests:
1. Null transform for content coming from remote server.
2. Null transform for content coming from the cache/disk.

We did observe increased CPU iowait and increased serving time only in the 
second case.
I'm not sure if this is the same issue, because the TS-2496 doesn't mention if 
the served content comes from the cache or from the remote server.

> High CPU iowait with null-transform on a content from the cache.
> 
>
> Key: TS-3753
> URL: https://issues.apache.org/jira/browse/TS-3753
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins, TS API
>Affects Versions: 5.3.0
>Reporter: Pavel Vazharov
> Fix For: 6.1.0
>
> Attachments: null-transform-cache.patch, usi.png
>
>
> Hi,
> I'm trying to calculate some stats doing null-transform on a content served 
> from the cache. However, I observed high CPU iowait when doing this. I 
> isolated the issue to be related to the case when we do transformation on a 
> content served from the cache. Please, see the attached few lines patch which 
> when applied to the null-transform plugin causes high CPU iowait. Note also 
> that when I tried the original null-transform plugin I didn't observe such 
> increased CPU iowait. Please, see also the attached picture where you can see 
> the increased  CPU iowait (between 15:30 and 16:30 in red) when I started the 
> test with null-transform from cache.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TS-3667) SSL Handhake read does not correctly handle EOF and error cases

[Oknet Xu (JIRA)]

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

Oknet Xu edited comment on TS-3667 at 7/22/15 9:42 AM:
---

this patch is also working for me but I'm prefer only {{if (retval == 0)}} 
section here.
Let SSL_Accept() to face other error status if retval < 0.

to replicate it, you can try {{plugins/experimental/ssl_cert_loader}}, the 
plugin load cert from file rather than my plugin load cert from mysql database.

sorry for my poor english, you are right, EAGAIN not means EOF, and may be some 
data will be send to client.

for SSL_accept(), it will call {{SSLUtils.cc::ssl_cert_callback}} or 
{{SSLUtils.cc::ssl_servername_callback}} to reenable the SSLVC during the ssl 
handshake process.


was (Author: oknet):
yes, the last simple patch is working for me.

to replicate it, you can try {{plugins/experimental/ssl_cert_loader}}, the 
plugin load cert from file rather than my plugin load cert from mysql database.

sorry for my poor english, you are right, EAGAIN not means EOF, and may be some 
data will send to client.

for SSL_accept(), it will call {{SSLUtils.cc::ssl_cert_callback}} or 
{{SSLUtils.cc::ssl_servername_callback}} to reenable the SSLVC during the ssl 
handshake process.

> SSL Handhake read does not correctly handle EOF and error cases
> ---
>
> Key: TS-3667
> URL: https://issues.apache.org/jira/browse/TS-3667
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Affects Versions: 5.2.0, 5.3.0
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 5.3.1, 6.0.0
>
> Attachments: ts-3667.diff
>
>
> Reported by [~esproul] and postwait.
> The return value of SSLNetVConnection::read_raw_data() is being ignored.  So 
> EOF and errors are not terminated, but rather spin until the inactivity 
> timeout is reached.  EAGAIN  is not being descheduled until more data is 
> available.
> This results in higher CPU utilization and hitting the SSL_error() function 
> much more than it needs to be hit.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3714) TS seems to stall between ua_begin and ua_first_read on some transactions resulting in high response times.

[Scott Beardsley (JIRA)]

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

Scott Beardsley commented on TS-3714:
-

We rolled this change out and started seeing some strangeness with the TLS 
handshakes (mostly over dual stack systems so possibly related to IPv6).

It looks like TCP connect() was completed successfully but then there was a 
hang where the browser just sits and spins. Eventually we get RSTs from the 
server after the client sent a FIN+ACK.

One thing I observed is that the client attempts to open the connection on both 
ipv4 and ipv6 at the same time... I wonder if there is some sort of race on ATS 
in these cases... 

> TS seems to stall between ua_begin and ua_first_read on some transactions 
> resulting in high response times.
> ---
>
> Key: TS-3714
> URL: https://issues.apache.org/jira/browse/TS-3714
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 5.3.0
>Reporter: Sudheer Vinukonda
>Assignee: Sudheer Vinukonda
> Fix For: 6.1.0
>
>
> An example slow log showing very high *ua_first_read*.
> {code}
> ERROR: [8624075] Slow Request: client_ip: xx.xx.xx.xxx url: 
> http://xx status: 200 unique id: bytes: 86 fd: 0 client 
> state: 0 serv
> er state: 9 ua_begin: 0.000 ua_first_read: 42.224 ua_read_header_done: 42.224 
> cache_open_rea
> d_begin: 42.224 cache_open_read_end: 42.224 dns_lookup_begin: 42.224 
> dns_lookup_end: 42.224
> server_connect: 42.224 server_first_read: 42.229 server_read_header_done: 
> 42.229 server_clos
> e: 42.229 ua_begin_write: 42.229 ua_close: 42.229 sm_finish: 42.229
> {code}
> Initially, I suspected that it might be caused by browser's connecting early 
> before sending any bytes to TS. However, this seems to be happening too 
> frequently and with unrealistically high delay between *ua_begin* and 
> *ua_first_read*.
> I suspect it's caused due to the code that disables the read temporarily 
> before calling *TXN_START* hook and re-enables it after the API call out. The 
> read disable is done via a 0-byte *do_io_read* on the client vc, but, the 
> problem is that a valid *mbuf* is still passed. Based on what I am seeing, 
> it's possible this results in actually enabling the *read_vio* all the way 
> uptil *ssl_read_from_net* for instance (if there's a race condition and there 
> were bytes already from the client resulting in an epoll read event), which 
> would finally disable the read since, the *ntodo* (nbytes) is 0. However, 
> this may result in the epoll event being lost until a new i/o happens from 
> the client. I'm trying out further experiments to confirm the theory. In most 
> cases, the read buffer already has some bytes by the time the http session 
> and http sm is created, which makes it just work. But, if there's a slight 
> delay in the receiving bytes after making a connection, the epoll mechanism 
> should read it, but, due to the way the temporary read disable is being done, 
> the event may be lost (this is coz, ATS uses the epoll edge triggered mode).
> Some history on this issue - 
> This issue has been a problem for a long time and affects both http and https 
> requests. When this issue was first reported, our router operations team 
> eventually closed it indicating that disabling *accept* threads resolved it 
> ([~yzlai] also reported similar observations and conclusions). It's possible 
> that the race condition window may be slightly reduced by disabling accept 
> threads, but, to the overall performance and through put, accept threads are 
> very important. I now notice that the issue still exists (regardless of 
> whether or not accept threads are enabled/disabled) and am testing further to 
> confirm the issue.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3780) Logs_xml: add logging field for incoming (interface) ip.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3780:
--
Labels: review  (was: )

> Logs_xml: add logging field for incoming (interface) ip.
> 
>
> Key: TS-3780
> URL: https://issues.apache.org/jira/browse/TS-3780
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Core, Logging
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>  Labels: review
> Fix For: 6.1.0
>
>
> It would be great if in a logs_xml config we could have it log the incoming 
> (interface) ip.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3781) Ability to log the The proxy request server port

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3781:
--
Fix Version/s: 6.1.0

> Ability to log the The proxy request server port
> 
>
> Key: TS-3781
> URL: https://issues.apache.org/jira/browse/TS-3781
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Logging
>Reporter: Jonh Wendell
>Assignee: Brian Geffon
>  Labels: review
> Fix For: 6.1.0
>
> Attachments: 0001-TS-3781-Add-the-log-field-pqsp-server-port.patch
>
>
> In addition to field "pqsi", it would be good to have the server port 
> available to logging as well.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3780) Logs_xml: add logging field for incoming (interface) ip.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3780:
--
Fix Version/s: 6.1.0

> Logs_xml: add logging field for incoming (interface) ip.
> 
>
> Key: TS-3780
> URL: https://issues.apache.org/jira/browse/TS-3780
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Core, Logging
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>  Labels: review
> Fix For: 6.1.0
>
>
> It would be great if in a logs_xml config we could have it log the incoming 
> (interface) ip.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3786) Use a consensus algorithm to elect the cluster master

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3786:
---

John, as I suggested separately, please

1) Fix formatting with clang-format.

2) Move copyright notices to our NOTICES file in git.


Thanks!

-- Leif


> Use a consensus algorithm to elect the cluster master
> -
>
> Key: TS-3786
> URL: https://issues.apache.org/jira/browse/TS-3786
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Manager
>Reporter: John Plevyak
>Assignee: John Plevyak
> Fix For: 6.1.0
>
>
> We should use a consensus algorithm to elect the cluster master and to update 
> the configurations so that there is no single point of failure and machines 
> entering or restarting can be brought to a consistent state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3782) Add tests for HTTP/2 in TSQA

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3782:
---

[~jacksontj] Please review.

> Add tests for HTTP/2 in TSQA
> 
>
> Key: TS-3782
> URL: https://issues.apache.org/jira/browse/TS-3782
> Project: Traffic Server
>  Issue Type: Test
>  Components: CI, HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Thomas Jackson
>  Labels: review
> Fix For: 6.1.0
>
> Attachments: normal_scenario_tests_001.patch
>
>
> Add tests for HTTP/2 in TSQA. IMO, it is better to add two types of tests for 
> HTTP/2 below.
> 1. Normal Scenario Tests
>   - Do HTTP requests with [hyper|https://github.com/lukasa/hyper] or other 
> HTTP/2 client.
> 2. Exceptional Scenario Tests
>   - [h2spec|https://github.com/summerwind/h2spec] looks good test tool for 
> edge cases of HTTP/2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3786) Use a consensus algorithm to elect the cluster master

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3786:
--
Fix Version/s: 6.1.0

> Use a consensus algorithm to elect the cluster master
> -
>
> Key: TS-3786
> URL: https://issues.apache.org/jira/browse/TS-3786
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Manager
>Reporter: John Plevyak
>Assignee: John Plevyak
> Fix For: 6.1.0
>
>
> We should use a consensus algorithm to elect the cluster master and to update 
> the configurations so that there is no single point of failure and machines 
> entering or restarting can be brought to a consistent state.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3782) Add tests for HTTP/2 in TSQA

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3782:
--
Fix Version/s: 6.1.0

> Add tests for HTTP/2 in TSQA
> 
>
> Key: TS-3782
> URL: https://issues.apache.org/jira/browse/TS-3782
> Project: Traffic Server
>  Issue Type: Test
>  Components: CI, HTTP/2
>Reporter: Masaori Koshiba
>  Labels: review
> Fix For: 6.1.0
>
> Attachments: normal_scenario_tests_001.patch
>
>
> Add tests for HTTP/2 in TSQA. IMO, it is better to add two types of tests for 
> HTTP/2 below.
> 1. Normal Scenario Tests
>   - Do HTTP requests with [hyper|https://github.com/lukasa/hyper] or other 
> HTTP/2 client.
> 2. Exceptional Scenario Tests
>   - [h2spec|https://github.com/summerwind/h2spec] looks good test tool for 
> edge cases of HTTP/2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3782) Add tests for HTTP/2 in TSQA

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3782:
--
Labels: review  (was: )

> Add tests for HTTP/2 in TSQA
> 
>
> Key: TS-3782
> URL: https://issues.apache.org/jira/browse/TS-3782
> Project: Traffic Server
>  Issue Type: Test
>  Components: CI, HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Thomas Jackson
>  Labels: review
> Fix For: 6.1.0
>
> Attachments: normal_scenario_tests_001.patch
>
>
> Add tests for HTTP/2 in TSQA. IMO, it is better to add two types of tests for 
> HTTP/2 below.
> 1. Normal Scenario Tests
>   - Do HTTP requests with [hyper|https://github.com/lukasa/hyper] or other 
> HTTP/2 client.
> 2. Exceptional Scenario Tests
>   - [h2spec|https://github.com/summerwind/h2spec] looks good test tool for 
> edge cases of HTTP/2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3779) Body Factory: support per hosts error pages.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3779:
--
Labels: review  (was: )

> Body Factory: support per hosts error pages.
> 
>
> Key: TS-3779
> URL: https://issues.apache.org/jira/browse/TS-3779
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Core
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>  Labels: review
> Fix For: 6.1.0
>
>
> Body Factory should support per-host error pages as it supports per-language 
> error pages today.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3782) Add tests for HTTP/2 in TSQA

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3782:
--
Assignee: Thomas Jackson

> Add tests for HTTP/2 in TSQA
> 
>
> Key: TS-3782
> URL: https://issues.apache.org/jira/browse/TS-3782
> Project: Traffic Server
>  Issue Type: Test
>  Components: CI, HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Thomas Jackson
>  Labels: review
> Fix For: 6.1.0
>
> Attachments: normal_scenario_tests_001.patch
>
>
> Add tests for HTTP/2 in TSQA. IMO, it is better to add two types of tests for 
> HTTP/2 below.
> 1. Normal Scenario Tests
>   - Do HTTP requests with [hyper|https://github.com/lukasa/hyper] or other 
> HTTP/2 client.
> 2. Exceptional Scenario Tests
>   - [h2spec|https://github.com/summerwind/h2spec] looks good test tool for 
> edge cases of HTTP/2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3779) Body Factory: support per hosts error pages.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3779:
--
Fix Version/s: 6.1.0

> Body Factory: support per hosts error pages.
> 
>
> Key: TS-3779
> URL: https://issues.apache.org/jira/browse/TS-3779
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Core
>Reporter: Brian Geffon
>Assignee: Brian Geffon
>  Labels: review
> Fix For: 6.1.0
>
>
> Body Factory should support per-host error pages as it supports per-language 
> error pages today.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3777) TSHttpConnect and POST request does not fire TS_VCONN_READ_COMPLETE nor TS_VCONN_EOS

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3777:
--
Fix Version/s: 6.1.0

> TSHttpConnect and POST request does not fire TS_VCONN_READ_COMPLETE nor 
> TS_VCONN_EOS
> 
>
> Key: TS-3777
> URL: https://issues.apache.org/jira/browse/TS-3777
> Project: Traffic Server
>  Issue Type: Bug
>  Components: TS API
>Reporter: Daniel Vitor Morilha
>  Labels: yahoo
> Fix For: 6.1.0
>
>
> When using TSHttpConnect to connect to ATS itself (internal vconnection), 
> sending a POST request and receiving a CHUNKED response. ATS does not fire 
> neither TS_VCONN_READ_COMPLETE nor TS_VCONN_EOS.
> Trying to close the vconnection from the plug-in after receiving the last 
> chunk ("\r\n0\r\n") results into the PluginVC repeating the following message:
> {noformat}
> [Jul 14 21:24:06.094] Server {0x77fbe800} DEBUG: (pvc_event) [0] Passive: 
> Received event 1
> {noformat}
> I am glad to provide an example if that helps.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3753) High CPU iowait with null-transform on a content from the cache.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3753:
---

Pavel, I wonder if this is a "dupe" of TS-2496 ? If so, would you mind moving 
your comments and patches / analysis to that one?

Thanks!

> High CPU iowait with null-transform on a content from the cache.
> 
>
> Key: TS-3753
> URL: https://issues.apache.org/jira/browse/TS-3753
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins, TS API
>Affects Versions: 5.3.0
>Reporter: Pavel Vazharov
> Fix For: 6.1.0
>
> Attachments: null-transform-cache.patch, usi.png
>
>
> Hi,
> I'm trying to calculate some stats doing null-transform on a content served 
> from the cache. However, I observed high CPU iowait when doing this. I 
> isolated the issue to be related to the case when we do transformation on a 
> content served from the cache. Please, see the attached few lines patch which 
> when applied to the null-transform plugin causes high CPU iowait. Note also 
> that when I tried the original null-transform plugin I didn't observe such 
> increased CPU iowait. Please, see also the attached picture where you can see 
> the increased  CPU iowait (between 15:30 and 16:30 in red) when I started the 
> test with null-transform from cache.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3667) SSL Handhake read does not correctly handle EOF and error cases

[Oknet Xu (JIRA)]

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

Oknet Xu commented on TS-3667:
--

yes, the last simple patch is working for me.

to replicate it, you can try {{plugins/experimental/ssl_cert_loader}}, the 
plugin load cert from file rather than my plugin load cert from mysql database.

sorry for my poor english, you are right, EAGAIN not means EOF, and may be some 
data will send to client.

for SSL_accept(), it will call {{SSLUtils.cc::ssl_cert_callback}} or 
{{SSLUtils.cc::ssl_servername_callback}} to reenable the SSLVC during the ssl 
handshake process.

> SSL Handhake read does not correctly handle EOF and error cases
> ---
>
> Key: TS-3667
> URL: https://issues.apache.org/jira/browse/TS-3667
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Affects Versions: 5.2.0, 5.3.0
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 5.3.1, 6.0.0
>
> Attachments: ts-3667.diff
>
>
> Reported by [~esproul] and postwait.
> The return value of SSLNetVConnection::read_raw_data() is being ignored.  So 
> EOF and errors are not terminated, but rather spin until the inactivity 
> timeout is reached.  EAGAIN  is not being descheduled until more data is 
> available.
> This results in higher CPU utilization and hitting the SSL_error() function 
> much more than it needs to be hit.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3753) High CPU iowait with null-transform on a content from the cache.

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-3753:
--
Fix Version/s: 6.1.0

> High CPU iowait with null-transform on a content from the cache.
> 
>
> Key: TS-3753
> URL: https://issues.apache.org/jira/browse/TS-3753
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins, TS API
>Affects Versions: 5.3.0
>Reporter: Pavel Vazharov
> Fix For: 6.1.0
>
> Attachments: null-transform-cache.patch, usi.png
>
>
> Hi,
> I'm trying to calculate some stats doing null-transform on a content served 
> from the cache. However, I observed high CPU iowait when doing this. I 
> isolated the issue to be related to the case when we do transformation on a 
> content served from the cache. Please, see the attached few lines patch which 
> when applied to the null-transform plugin causes high CPU iowait. Note also 
> that when I tried the original null-transform plugin I didn't observe such 
> increased CPU iowait. Please, see also the attached picture where you can see 
> the increased  CPU iowait (between 15:30 and 16:30 in red) when I started the 
> test with null-transform from cache.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-2496) Null transform plugin set 50% bandwidth capcability

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-2496:
--
Fix Version/s: (was: sometime)
   6.1.0

> Null transform plugin set 50% bandwidth capcability
> ---
>
> Key: TS-2496
> URL: https://issues.apache.org/jira/browse/TS-2496
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: Roee Gil
> Fix For: 6.1.0
>
> Attachments: speedTestNoTransform.png, speedTestWithTransform.png
>
>
> When using null transform example (as is), I get bandwidth capacity reduced 
> to half and worst.
> testing the connection speed at: http://www.speedtest.net/



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TS-3787) Don't allow blacklisted HTTP/2 ciphers to use HTTP/2

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom edited comment on TS-3787 at 7/22/15 8:55 AM:


To clarify, the corresponding public API is TSNetAcceptNamedProtocol(), which 
would need to be changed to

{code}
tsapi TSReturnCode TSNetAcceptNamedProtocol(TSCont contp, const char *protocol, 
const char *whitelisted_ciphers, const char *blacklisted_ciphers);
{code}


was (Author: zwoop):
To clarify, the corresponding public API is, which would need to be changed to

{code}
tsapi TSReturnCode TSNetAcceptNamedProtocol(TSCont contp, const char *protocol, 
const char *whitelisted_ciphers, const char *blacklisted_ciphers);
{code}

> Don't allow blacklisted HTTP/2 ciphers to use HTTP/2
> 
>
> Key: TS-3787
> URL: https://issues.apache.org/jira/browse/TS-3787
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Bryan Call
>  Labels: yahoo
> Fix For: 6.1.0
>
>
> Look at the selected cipher and if it is on the blacklist then don't allow 
> the client to use HTTP/2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3787) Don't allow blacklisted HTTP/2 ciphers to use HTTP/2

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3787:
---

To clarify, the corresponding public API is, which would need to be changed to

{code}
tsapi TSReturnCode TSNetAcceptNamedProtocol(TSCont contp, const char *protocol, 
const char *whitelisted_ciphers, const char *blacklisted_ciphers);
{code}

> Don't allow blacklisted HTTP/2 ciphers to use HTTP/2
> 
>
> Key: TS-3787
> URL: https://issues.apache.org/jira/browse/TS-3787
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Bryan Call
>  Labels: yahoo
> Fix For: 6.1.0
>
>
> Look at the selected cipher and if it is on the blacklist then don't allow 
> the client to use HTTP/2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Comment Edited] (TS-3787) Don't allow blacklisted HTTP/2 ciphers to use HTTP/2

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom edited comment on TS-3787 at 7/22/15 8:48 AM:


Maybe we need e.g.

{code}
SSLNextProtocolAccept::registerEndpoint(const char *protocol, Continuation 
*handler, char *whitelisted_ciphers=NULL, char *blacklisted_ciphers=NULL);
{code}

This also opens up the issue of the public APIs, do we also make similar 
additions to that API? If so, we really have to get that in for 6.0.0, like, 
right now! Even if it's just adding / changing the prototypes accordingly, 
without the underlying core code, we should make those API changes now.



was (Author: zwoop):
Maybe we need e.g.

{code}
SSLNextProtocolAccept::registerEndpoint(const char *protocol, Continuation 
*handler, char *whitelisted_siphers=NULL, char *blacklisted_ciphers=NULL);
{code}

This also opens up the issue of the public APIs, do we also make similar 
additions to that API? If so, we really have to get that in for 6.0.0, like, 
right now! Even if it's just adding / changing the prototypes accordingly, 
without the underlying core code, we should make those API changes now.


> Don't allow blacklisted HTTP/2 ciphers to use HTTP/2
> 
>
> Key: TS-3787
> URL: https://issues.apache.org/jira/browse/TS-3787
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Bryan Call
>  Labels: yahoo
> Fix For: 6.1.0
>
>
> Look at the selected cipher and if it is on the blacklist then don't allow 
> the client to use HTTP/2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Commented] (TS-3787) Don't allow blacklisted HTTP/2 ciphers to use HTTP/2

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3787:
---

Maybe we need e.g.

{code}
SSLNextProtocolAccept::registerEndpoint(const char *protocol, Continuation 
*handler, char *whitelisted_siphers=NULL, char *blacklisted_ciphers=NULL);
{code}

This also opens up the issue of the public APIs, do we also make similar 
additions to that API? If so, we really have to get that in for 6.0.0, like, 
right now! Even if it's just adding / changing the prototypes accordingly, 
without the underlying core code, we should make those API changes now.


> Don't allow blacklisted HTTP/2 ciphers to use HTTP/2
> 
>
> Key: TS-3787
> URL: https://issues.apache.org/jira/browse/TS-3787
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Bryan Call
>  Labels: yahoo
> Fix For: 6.1.0
>
>
> Look at the selected cipher and if it is on the blacklist then don't allow 
> the client to use HTTP/2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Updated] (TS-3787) Don't allow blacklisted HTTP/2 ciphers to use HTTP/2

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3787:
---
Fix Version/s: 6.1.0

> Don't allow blacklisted HTTP/2 ciphers to use HTTP/2
> 
>
> Key: TS-3787
> URL: https://issues.apache.org/jira/browse/TS-3787
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Bryan Call
>  Labels: yahoo
> Fix For: 6.1.0
>
>
> Look at the selected cipher and if it is on the blacklist then don't allow 
> the client to use HTTP/2.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)