Build failed in Jenkins: clang-analyzer #2700

[jenkins]

See 

Changes:

[James Peach] TS-4955: Assign the Plugin VC acceptor at allocation time.

[James Peach] TS-4955: Allow Plugin VC accept continuation to be unlocked.

[James Peach] TS-4961: Use default accept thread config for plugin accepts.

--
[...truncated 5404 lines...]
reading sources... [ 69%] developer-guide/api/functions/TSVIOMutexGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONBytesGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONBytesSet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONDoneGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONDoneSet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONTodoGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReaderGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReenable.en
reading sources... [ 71%] developer-guide/api/functions/TSVIOVConnGet.en
reading sources... [ 71%] developer-guide/api/functions/TSfclose.en
reading sources... [ 71%] developer-guide/api/functions/TSfflush.en
reading sources... [ 71%] developer-guide/api/functions/TSfgets.en
reading sources... [ 71%] developer-guide/api/functions/TSfopen.en
reading sources... [ 72%] developer-guide/api/functions/TSfread.en
reading sources... [ 72%] developer-guide/api/functions/TSfwrite.en
reading sources... [ 72%] developer-guide/api/functions/TSmalloc.en
reading sources... [ 72%] developer-guide/api/functions/index.en
reading sources... [ 73%] developer-guide/api/index.en
reading sources... [ 73%] developer-guide/api/types/TSCacheDataType.en
reading sources... [ 73%] developer-guide/api/types/TSCacheError.en
reading sources... [ 73%] developer-guide/api/types/TSCacheLookupResult.en
reading sources... [ 73%] developer-guide/api/types/TSCacheScanResult.en
reading sources... [ 74%] developer-guide/api/types/TSEvent.en
reading sources... [ 74%] developer-guide/api/types/TSFetchWakeUpOptions.en
reading sources... [ 74%] developer-guide/api/types/TSHttpHookID.en
reading sources... [ 74%] developer-guide/api/types/TSHttpStatus.en
reading sources... [ 75%] developer-guide/api/types/TSHttpType.en
reading sources... [ 75%] developer-guide/api/types/TSIOBuffersSizeIndex.en
reading sources... [ 75%] developer-guide/api/types/TSLifecycleHookID.en
reading sources... [ 75%] developer-guide/api/types/TSLookingUpType.en
reading sources... [ 75%] developer-guide/api/types/TSMilestonesType.en
reading sources... [ 76%] developer-guide/api/types/TSOverridableConfigKey.en
reading sources... [ 76%] developer-guide/api/types/TSParseResult.en
reading sources... [ 76%] developer-guide/api/types/TSRecordAccessType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordCheckType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordDataType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordModeType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordPersistType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordUpdateType.en
reading sources... [ 78%] developer-guide/api/types/TSReturnCode.en
reading sources... [ 78%] developer-guide/api/types/TSSDKVersion.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingMatchType.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingPoolType.en
reading sources... [ 78%] developer-guide/api/types/TSServerState.en
reading sources... [ 79%] developer-guide/api/types/TSStatPeristence.en
reading sources... [ 79%] developer-guide/api/types/TSStatSync.en
reading sources... [ 79%] developer-guide/api/types/TSThreadPool.en
reading sources... [ 79%] developer-guide/api/types/TSUuid.en
reading sources... [ 80%] developer-guide/api/types/TSVConnCloseFlags.en
reading sources... [ 80%] developer-guide/api/types/index.en
reading sources... [ 80%] developer-guide/architecture/api-functions.en
reading sources... [ 80%] developer-guide/architecture/architecture.en
reading sources... [ 80%] developer-guide/architecture/consistency.en
reading sources... [ 81%] developer-guide/architecture/data-structures.en
reading sources... [ 81%] developer-guide/architecture/index.en
reading sources... [ 81%] developer-guide/architecture/ram-cache.en
reading sources... [ 81%] developer-guide/architecture/tiered-storage.en
reading sources... [ 82%] developer-guide/config-vars.en
reading sources... [ 82%] developer-guide/continuous-integration/index.en
reading sources... [ 82%] developer-guide/contributing/index.en
reading sources... [ 82%] developer-guide/debugging/core-dump-analysis.en
reading sources... [ 82%] developer-guide/debugging/debug-builds.en
reading sources... [ 83%] developer-guide/debugging/debug-tags.en
reading sources... [ 83%] developer-guide/debugging/index.en
reading sources... [ 83%] 

[jira] [Created] (TS-4965) max_unavailable_server_retries always uses 1

[Miles Libbey (JIRA)]

Miles Libbey created TS-4965:


 Summary: max_unavailable_server_retries always uses 1
 Key: TS-4965
 URL: https://issues.apache.org/jira/browse/TS-4965
 Project: Traffic Server
  Issue Type: Bug
  Components: Parent Proxy
Reporter: Miles Libbey


When testing max_unavailable_server_retries with 6.2, we set 6 parents that 
were not reachable by the child, using consistent_hash. We set 
max_unavailable_server_retries to 2,3, and 4, and launched ATS with the parent 
debug tag. We saw the child fail to connect to the 1st parent, then retry to a 
2nd parent, but never to a 3rd. 



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

[jira] [Commented] (TS-4964) max_unavailable_server_retries can't be 5

[James Peach (JIRA)]

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

James Peach commented on TS-4964:
-

Why limit to 5?

> max_unavailable_server_retries can't be 5
> -
>
> Key: TS-4964
> URL: https://issues.apache.org/jira/browse/TS-4964
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Parent Proxy
>Reporter: Miles Libbey
>
> Don't know if this is a documentation bug or a code bug.
> https://docs.trafficserver.apache.org/en/latest/admin-guide/files/parent.config.en.html
>  says,
> "By default the value for max_unavailable_server_retries is 1. It may be set 
> to any value in the range 1 to 5"
> Testing with 6.2, when we set max_unavailable_server_retries=5, the setting 
> is ignored (used parent debug tag to see this). When set to <=4, the 
> max_unavailable_server_retries is set.



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

[jira] [Created] (TS-4964) max_unavailable_server_retries can't be 5

[Miles Libbey (JIRA)]

Miles Libbey created TS-4964:


 Summary: max_unavailable_server_retries can't be 5
 Key: TS-4964
 URL: https://issues.apache.org/jira/browse/TS-4964
 Project: Traffic Server
  Issue Type: Bug
  Components: Parent Proxy
Reporter: Miles Libbey


Don't know if this is a documentation bug or a code bug.

https://docs.trafficserver.apache.org/en/latest/admin-guide/files/parent.config.en.html
 says,
"By default the value for max_unavailable_server_retries is 1. It may be set to 
any value in the range 1 to 5"

Testing with 6.2, when we set max_unavailable_server_retries=5, the setting is 
ignored (used parent debug tag to see this). When set to <=4, the 
max_unavailable_server_retries is set.



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

[jira] [Resolved] (TS-4961) Plugin accept should use default thread counts.

[James Peach (JIRA)]

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

James Peach resolved TS-4961.
-
   Resolution: Fixed
 Assignee: James Peach
Fix Version/s: 7.1.0

> Plugin accept should use default thread counts.
> ---
>
> Key: TS-4961
> URL: https://issues.apache.org/jira/browse/TS-4961
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {{TSPortDescriptorAccept}} and {{TSPluginDescriptorAccept}} both explicity 
> pass a 0 thread count to {{make_net_accept}}. Since there is no API for the 
> plugin to specify what is needed (unlike {{TSNetAccept}}), the principle of 
> least surprise would suggest we use the default config from 
> {{proxy.config.accept_threads}}.



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

[jira] [Resolved] (TS-4955) Remove the global mutex from the plugin session acceptor

[James Peach (JIRA)]

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

James Peach resolved TS-4955.
-
   Resolution: Fixed
 Assignee: James Peach
Fix Version/s: 7.1.0

> Remove the global mutex from the plugin session acceptor
> 
>
> Key: TS-4955
> URL: https://issues.apache.org/jira/browse/TS-4955
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Performance
>Reporter: James Peach
>Assignee: James Peach
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> {{plugin_http_accept}} has a global mutex which gets contended by protocol 
> plugins. We don't require locking on {{HttpSessionAccept}} objects and the 
> normal server port accept objects are not locked.



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

Failed: trafficserver (latest)

[Read the Docs]

Build Failed for trafficserver (latest)



Error:
Version locked, retrying in 5 minutes.

You can find out more about this failure here:
https://readthedocs.org/projects/trafficserver/builds/4508062/

If you have questions, a good place to start is the FAQ:
https://docs.readthedocs.org/en/latest/faq.html



Keep documenting,
Read the Docs
--
http://readthedocs.org

[GitHub] trafficserver pull request #1098: TS-4961: Use default accept thread config ...

[jpeach]

Github user jpeach closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TS-4829) Via: header string should not be cached

[Miles Libbey (JIRA)]

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

Miles Libbey commented on TS-4829:
--

Changed Documentation to note that any previous hierarchy data is cached. 

> Via: header string should not be cached
> ---
>
> Key: TS-4829
> URL: https://issues.apache.org/jira/browse/TS-4829
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Miles Libbey
> Fix For: sometime
>
>
> We use a cache hierarchy.  In theory the Via: string shows the path the 
> request took through proxies, and with 
> proxy.config.http.insert_response_via_str set to 3, a lot of info is 
> presented -- cache hit, etc. (The Via header is described in 
> https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.45)
> However, the string is cached, so it doesn't accurately reflect the path that 
> *this* request took. Instead, it shows the path of the original request.
> For instance, imagine 2 servers, conveniently named child.example.com and 
> parent.example.com, which also represents their roles in the cache hierarchy. 
> The object is cacheable for a long time.
> The first request for the object might look like:
> Via: http/1.1 parent.example.com (ApacheTrafficServer/6.2.1 [uScMsSfWpSeN:t 
> cCMi p sS]), http/1.1 child.example.com (ApacheTrafficServer/6.2.1 [uScMsSf 
> pSeN:t cCMi pSs ])
> (with the cM meaning cache miss). The second request, a cache hit that just 
> goes through child.example.com might show:
> Via: http/1.1 parent.example.com (ApacheTrafficServer/6.2.1 [uScMsSfWpSeN:t 
> cCMi p sS]), http/1.1 child.example.com (ApacheTrafficServer/6.2.1[uScHs f p 
> eN:t cCHi p s ])
> eg, cache Hit for child, but cache Miss for parent -- even though the parent 
> wasn't involved in the request, and, if it were, it would be a Hit.  The 
> parent portion was cached by child.example.com.
> The expected behavior is that the 2nd request would yield:
> Via: http/1.1 child.example.com (ApacheTrafficServer/6.2.1[uScHs f p eN:t 
> cCHi p s ])



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

[jira] [Resolved] (TS-4829) Via: header string should not be cached

[Miles Libbey (JIRA)]

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

Miles Libbey resolved TS-4829.
--
Resolution: Fixed

> Via: header string should not be cached
> ---
>
> Key: TS-4829
> URL: https://issues.apache.org/jira/browse/TS-4829
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: Miles Libbey
> Fix For: sometime
>
>
> We use a cache hierarchy.  In theory the Via: string shows the path the 
> request took through proxies, and with 
> proxy.config.http.insert_response_via_str set to 3, a lot of info is 
> presented -- cache hit, etc. (The Via header is described in 
> https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.45)
> However, the string is cached, so it doesn't accurately reflect the path that 
> *this* request took. Instead, it shows the path of the original request.
> For instance, imagine 2 servers, conveniently named child.example.com and 
> parent.example.com, which also represents their roles in the cache hierarchy. 
> The object is cacheable for a long time.
> The first request for the object might look like:
> Via: http/1.1 parent.example.com (ApacheTrafficServer/6.2.1 [uScMsSfWpSeN:t 
> cCMi p sS]), http/1.1 child.example.com (ApacheTrafficServer/6.2.1 [uScMsSf 
> pSeN:t cCMi pSs ])
> (with the cM meaning cache miss). The second request, a cache hit that just 
> goes through child.example.com might show:
> Via: http/1.1 parent.example.com (ApacheTrafficServer/6.2.1 [uScMsSfWpSeN:t 
> cCMi p sS]), http/1.1 child.example.com (ApacheTrafficServer/6.2.1[uScHs f p 
> eN:t cCHi p s ])
> eg, cache Hit for child, but cache Miss for parent -- even though the parent 
> wasn't involved in the request, and, if it were, it would be a Hit.  The 
> parent portion was cached by child.example.com.
> The expected behavior is that the 2nd request would yield:
> Via: http/1.1 child.example.com (ApacheTrafficServer/6.2.1[uScHs f p eN:t 
> cCHi p s ])



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

[jira] [Work logged] (TS-4961) Plugin accept should use default thread counts.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4961?focusedWorklogId=30563=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30563
 ]

ASF GitHub Bot logged work on TS-4961:
--

Author: ASF GitHub Bot
Created on: 13/Oct/16 03:46
Start Date: 13/Oct/16 03:46
Worklog Time Spent: 10m 
  Work Description: Github user jpeach closed the pull request at:

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


Issue Time Tracking
---

Worklog Id: (was: 30563)
Time Spent: 40m  (was: 0.5h)

> Plugin accept should use default thread counts.
> ---
>
> Key: TS-4961
> URL: https://issues.apache.org/jira/browse/TS-4961
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Peach
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {{TSPortDescriptorAccept}} and {{TSPluginDescriptorAccept}} both explicity 
> pass a 0 thread count to {{make_net_accept}}. Since there is no API for the 
> plugin to specify what is needed (unlike {{TSNetAccept}}), the principle of 
> least surprise would suggest we use the default config from 
> {{proxy.config.accept_threads}}.



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

[jira] [Work logged] (TS-4955) Remove the global mutex from the plugin session acceptor

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4955?focusedWorklogId=30562=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30562
 ]

ASF GitHub Bot logged work on TS-4955:
--

Author: ASF GitHub Bot
Created on: 13/Oct/16 03:45
Start Date: 13/Oct/16 03:45
Worklog Time Spent: 10m 
  Work Description: Github user jpeach closed the pull request at:

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


Issue Time Tracking
---

Worklog Id: (was: 30562)
Time Spent: 1h 10m  (was: 1h)

> Remove the global mutex from the plugin session acceptor
> 
>
> Key: TS-4955
> URL: https://issues.apache.org/jira/browse/TS-4955
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Performance
>Reporter: James Peach
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> {{plugin_http_accept}} has a global mutex which gets contended by protocol 
> plugins. We don't require locking on {{HttpSessionAccept}} objects and the 
> normal server port accept objects are not locked.



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

[GitHub] trafficserver pull request #1096: TS-4955: Remove the global mutex from the ...

[jpeach]

Github user jpeach closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4915) Crash from hostdb in PriorityQueueLess

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4915?focusedWorklogId=30561=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30561
 ]

ASF GitHub Bot logged work on TS-4915:
--

Author: ASF GitHub Bot
Created on: 13/Oct/16 02:19
Start Date: 13/Oct/16 02:19
Worklog Time Spent: 10m 
  Work Description: Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/1088
  
I have been running this in production without an issue.  However, I still 
have a comment in the code about the !empt() conditional and the bubble_up 
function call.


Issue Time Tracking
---

Worklog Id: (was: 30561)
Time Spent: 5.5h  (was: 5h 20m)

> Crash from hostdb in PriorityQueueLess
> --
>
> Key: TS-4915
> URL: https://issues.apache.org/jira/browse/TS-4915
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Susan Hinrichs
>Priority: Blocker
> Fix For: 7.1.0
>
> Attachments: ts-4915.diff, ts-4915.diff
>
>  Time Spent: 5.5h
>  Remaining Estimate: 0h
>
> Saw this while testing fix for TS-4813 with debug enabled.
> {code}
> (gdb) bt full
> #0  0x00547bfe in RefCountCacheHashEntry::operator< (this=0x1cc0880, 
> v2=...) at ../iocore/hostdb/P_RefCountCache.h:94
> No locals.
> #1  0x0054988d in 
> PriorityQueueLess::operator() (this=0x2b78a9a2587b, 
> a=@0x2b78f402af68, b=@0x2b78f402aa28)
> at ../lib/ts/PriorityQueue.h:41
> No locals.
> #2  0x00549785 in PriorityQueue PriorityQueueLess >::_bubble_up (this=0x1cb2990, 
> index=2) at ../lib/ts/PriorityQueue.h:191
> comp = {}
> parent = 0
> #3  0x006ecfcc in PriorityQueue PriorityQueueLess >::push (this=0x1cb2990, 
> entry=0x2b78f402af60) at ../../lib/ts/PriorityQueue.h:91
> len = 2
> #4  0x006ec206 in RefCountCachePartition::put 
> (this=0x1cb2900, key=6912554662447498853, item=0x2b78aee04f00, size=96, 
> expire_time=1475202356) at ./P_RefCountCache.h:210
> expiry_entry = 0x2b78f402af60
> __func__ = "put"
> val = 0x1cc0880
> #5  0x006eb3de in RefCountCache::put (this=0x18051e0, 
> key=6912554662447498853, item=0x2b78aee04f00, size=16, 
> expiry_time=1475202356) at ./P_RefCountCache.h:462
> No locals.
> #6  0x006e2d8e in HostDBContinuation::dnsEvent (this=0x2b7938020f00, 
> event=600, e=0x2b78ac009440) at HostDB.cc:1422
> is_rr = false
> old_rr_data = 0x0
> first_record = 0x2b78ac0094f8
> m = 0x1
> failed = false
> old_r = {m_ptr = 0x0}
> af = 2 '\002'
> s_size = 16
> rrsize = 0
> allocSize = 16
> r = 0x2b78aee04f00
> old_info = { = { = {_vptr.ForceVFPTToTop 
> = 0x7f3630}, m_refcount = 0}, iobuffer_index = 0, 
>   key = 47797242059264, app = {allotment = {application1 = 5326300, 
> application2 = 0}, http_data = {http_version = 4, 
>   pipeline_max = 59, keepalive_timeout = 17, fail_count = 81, 
> unused1 = 0, last_failure = 0}, rr = {offset = 5326300}}, data = {
> ip = {sa = {sa_family = 54488, sa_data = 
> "^\000\000\000\000\000\020\034$\274x+\000"}, sin = {sin_family = 54488, 
> sin_port = 94, 
> sin_addr = {s_addr = 0}, sin_zero = "\020\034$\274x+\000"}, 
> sin6 = {sin6_family = 54488, sin6_port = 94, sin6_flowinfo = 0, 
> sin6_addr = {__in6_u = {__u6_addr8 = 
> "\020\034$\274x+\000\000\030\036$\274\375\b\000", __u6_addr16 = {7184, 48164, 
> 11128, 
>   0, 7704, 48164, 2301, 0}, __u6_addr32 = {3156483088, 
> 11128, 3156483608, 2301}}}, sin6_scope_id = 3156478176}}, 
> hostname_offset = 6214872, srv = {srv_offset = 54488, srv_weight 
> = 94, srv_priority = 0, srv_port = 0, key = 3156483088}}, 
>   hostname_offset = 11128, ip_timestamp = 2845989456, 
> ip_timeout_interval = 11128, is_srv = 0, reverse_dns = 0, round_robin = 1, 
>   round_robin_elt = 0}
> valid_records = 0
> tip = {_family = 2, _addr = {_ip4 = 540420056, _ip6 = {__in6_u = 
> {__u6_addr8 = "\330'6 x+\000\000\360L\020\250x+\000", 
> __u6_addr16 = {10200, 8246, 11128, 0, 19696, 43024, 11128, 
> 0}, __u6_addr32 = {540420056, 11128, 2819640560, 11128}}}, 
> _byte = "\330'6 x+\000\000\360L\020\250x+\000", _u32 = 
> {540420056, 11128, 2819640560, 11128}, _u64 = {47794936489944, 
>   47797215710448}}}
> ttl_seconds = 132
> aname = 0x2b7938021000 "fbmm1.zenfs.com"
> offset = 96
> thread = 0x2b78a8101010
> __func__ = "dnsEvent"
> #7  

[GitHub] trafficserver issue #1088: TS-4915: Crash from hostdb in PriorityQueueLess

[bryancall]

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/1088
  
I have been running this in production without an issue.  However, I still 
have a comment in the code about the !empt() conditional and the bubble_up 
function call.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TS-4947) Collation Server is broken?

[bettydramit (JIRA)]

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

bettydramit commented on TS-4947:
-

It dosn't work with this patch！
It works only for(  CollationHosts =  '192.168.2.33:8085' )

> Collation Server is broken?
> ---
>
> Key: TS-4947
> URL: https://issues.apache.org/jira/browse/TS-4947
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Logging
>Affects Versions: 7.0.0
>Reporter: bettydramit
>Assignee: James Peach
>Priority: Critical
> Fix For: 7.1.0
>
>
> from gitmaster(github.com/apache/trafficserver)
> config Collation Client 
> {code:xml}
> CONFIG proxy.config.url_remap.filename STRING remap.config
> CONFIG proxy.config.log.config.filename STRING logging.config
> CONFIG proxy.config.log.collation_host STRING 192.168.2.33
> CONFIG proxy.config.log.collation_secret STRING testlog
> LOCAL proxy.local.log.collation_mode INT 2
> CONFIG proxy.config.log.collation_port INT 8085
> {code}
> config Collation Server
> {code:xml}
> CONFIG proxy.local.log.collation_mode INT 1
> CONFIG proxy.config.log.collation_port INT 8085
> CONFIG proxy.config.log.collation_secret STRING testlog
> {code}
> logging.config
> {code:xml}
> w3c = format {
>   Format='% %<{Cdn-Real-Ip}cqh> - % [%] \"% % 
> %\" % % \"%<{Referer}cqh>\" \"%<{user-agent}cqh>\" % 
> % % % % % %'
> }
> log.ascii {
>   Filename = 'c11',
>   Format = w3c,
>   CollationHosts = { '192.168.2.33:8085' }
> }
> {code}
> It still flush log to local disk not to remote collation server



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

[jira] [Work logged] (TS-4915) Crash from hostdb in PriorityQueueLess

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4915?focusedWorklogId=30560=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30560
 ]

ASF GitHub Bot logged work on TS-4915:
--

Author: ASF GitHub Bot
Created on: 13/Oct/16 01:51
Start Date: 13/Oct/16 01:51
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1088
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/883/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30560)
Time Spent: 5h 20m  (was: 5h 10m)

> Crash from hostdb in PriorityQueueLess
> --
>
> Key: TS-4915
> URL: https://issues.apache.org/jira/browse/TS-4915
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Susan Hinrichs
>Priority: Blocker
> Fix For: 7.1.0
>
> Attachments: ts-4915.diff, ts-4915.diff
>
>  Time Spent: 5h 20m
>  Remaining Estimate: 0h
>
> Saw this while testing fix for TS-4813 with debug enabled.
> {code}
> (gdb) bt full
> #0  0x00547bfe in RefCountCacheHashEntry::operator< (this=0x1cc0880, 
> v2=...) at ../iocore/hostdb/P_RefCountCache.h:94
> No locals.
> #1  0x0054988d in 
> PriorityQueueLess::operator() (this=0x2b78a9a2587b, 
> a=@0x2b78f402af68, b=@0x2b78f402aa28)
> at ../lib/ts/PriorityQueue.h:41
> No locals.
> #2  0x00549785 in PriorityQueue PriorityQueueLess >::_bubble_up (this=0x1cb2990, 
> index=2) at ../lib/ts/PriorityQueue.h:191
> comp = {}
> parent = 0
> #3  0x006ecfcc in PriorityQueue PriorityQueueLess >::push (this=0x1cb2990, 
> entry=0x2b78f402af60) at ../../lib/ts/PriorityQueue.h:91
> len = 2
> #4  0x006ec206 in RefCountCachePartition::put 
> (this=0x1cb2900, key=6912554662447498853, item=0x2b78aee04f00, size=96, 
> expire_time=1475202356) at ./P_RefCountCache.h:210
> expiry_entry = 0x2b78f402af60
> __func__ = "put"
> val = 0x1cc0880
> #5  0x006eb3de in RefCountCache::put (this=0x18051e0, 
> key=6912554662447498853, item=0x2b78aee04f00, size=16, 
> expiry_time=1475202356) at ./P_RefCountCache.h:462
> No locals.
> #6  0x006e2d8e in HostDBContinuation::dnsEvent (this=0x2b7938020f00, 
> event=600, e=0x2b78ac009440) at HostDB.cc:1422
> is_rr = false
> old_rr_data = 0x0
> first_record = 0x2b78ac0094f8
> m = 0x1
> failed = false
> old_r = {m_ptr = 0x0}
> af = 2 '\002'
> s_size = 16
> rrsize = 0
> allocSize = 16
> r = 0x2b78aee04f00
> old_info = { = { = {_vptr.ForceVFPTToTop 
> = 0x7f3630}, m_refcount = 0}, iobuffer_index = 0, 
>   key = 47797242059264, app = {allotment = {application1 = 5326300, 
> application2 = 0}, http_data = {http_version = 4, 
>   pipeline_max = 59, keepalive_timeout = 17, fail_count = 81, 
> unused1 = 0, last_failure = 0}, rr = {offset = 5326300}}, data = {
> ip = {sa = {sa_family = 54488, sa_data = 
> "^\000\000\000\000\000\020\034$\274x+\000"}, sin = {sin_family = 54488, 
> sin_port = 94, 
> sin_addr = {s_addr = 0}, sin_zero = "\020\034$\274x+\000"}, 
> sin6 = {sin6_family = 54488, sin6_port = 94, sin6_flowinfo = 0, 
> sin6_addr = {__in6_u = {__u6_addr8 = 
> "\020\034$\274x+\000\000\030\036$\274\375\b\000", __u6_addr16 = {7184, 48164, 
> 11128, 
>   0, 7704, 48164, 2301, 0}, __u6_addr32 = {3156483088, 
> 11128, 3156483608, 2301}}}, sin6_scope_id = 3156478176}}, 
> hostname_offset = 6214872, srv = {srv_offset = 54488, srv_weight 
> = 94, srv_priority = 0, srv_port = 0, key = 3156483088}}, 
>   hostname_offset = 11128, ip_timestamp = 2845989456, 
> ip_timeout_interval = 11128, is_srv = 0, reverse_dns = 0, round_robin = 1, 
>   round_robin_elt = 0}
> valid_records = 0
> tip = {_family = 2, _addr = {_ip4 = 540420056, _ip6 = {__in6_u = 
> {__u6_addr8 = "\330'6 x+\000\000\360L\020\250x+\000", 
> __u6_addr16 = {10200, 8246, 11128, 0, 19696, 43024, 11128, 
> 0}, __u6_addr32 = {540420056, 11128, 2819640560, 11128}}}, 
> _byte = "\330'6 x+\000\000\360L\020\250x+\000", _u32 = 
> {540420056, 11128, 2819640560, 11128}, _u64 = {47794936489944, 
>   47797215710448}}}
> ttl_seconds = 132
> aname = 0x2b7938021000 "fbmm1.zenfs.com"
> offset = 96
> thread = 0x2b78a8101010
> __func__ = "dnsEvent"
> #7  0x005145dc in Continuation::handleEvent 

[GitHub] trafficserver issue #1088: TS-4915: Crash from hostdb in PriorityQueueLess

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1088
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/883/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4915) Crash from hostdb in PriorityQueueLess

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4915?focusedWorklogId=30559=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30559
 ]

ASF GitHub Bot logged work on TS-4915:
--

Author: ASF GitHub Bot
Created on: 13/Oct/16 01:46
Start Date: 13/Oct/16 01:46
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1088
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/991/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30559)
Time Spent: 5h 10m  (was: 5h)

> Crash from hostdb in PriorityQueueLess
> --
>
> Key: TS-4915
> URL: https://issues.apache.org/jira/browse/TS-4915
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Susan Hinrichs
>Priority: Blocker
> Fix For: 7.1.0
>
> Attachments: ts-4915.diff, ts-4915.diff
>
>  Time Spent: 5h 10m
>  Remaining Estimate: 0h
>
> Saw this while testing fix for TS-4813 with debug enabled.
> {code}
> (gdb) bt full
> #0  0x00547bfe in RefCountCacheHashEntry::operator< (this=0x1cc0880, 
> v2=...) at ../iocore/hostdb/P_RefCountCache.h:94
> No locals.
> #1  0x0054988d in 
> PriorityQueueLess::operator() (this=0x2b78a9a2587b, 
> a=@0x2b78f402af68, b=@0x2b78f402aa28)
> at ../lib/ts/PriorityQueue.h:41
> No locals.
> #2  0x00549785 in PriorityQueue PriorityQueueLess >::_bubble_up (this=0x1cb2990, 
> index=2) at ../lib/ts/PriorityQueue.h:191
> comp = {}
> parent = 0
> #3  0x006ecfcc in PriorityQueue PriorityQueueLess >::push (this=0x1cb2990, 
> entry=0x2b78f402af60) at ../../lib/ts/PriorityQueue.h:91
> len = 2
> #4  0x006ec206 in RefCountCachePartition::put 
> (this=0x1cb2900, key=6912554662447498853, item=0x2b78aee04f00, size=96, 
> expire_time=1475202356) at ./P_RefCountCache.h:210
> expiry_entry = 0x2b78f402af60
> __func__ = "put"
> val = 0x1cc0880
> #5  0x006eb3de in RefCountCache::put (this=0x18051e0, 
> key=6912554662447498853, item=0x2b78aee04f00, size=16, 
> expiry_time=1475202356) at ./P_RefCountCache.h:462
> No locals.
> #6  0x006e2d8e in HostDBContinuation::dnsEvent (this=0x2b7938020f00, 
> event=600, e=0x2b78ac009440) at HostDB.cc:1422
> is_rr = false
> old_rr_data = 0x0
> first_record = 0x2b78ac0094f8
> m = 0x1
> failed = false
> old_r = {m_ptr = 0x0}
> af = 2 '\002'
> s_size = 16
> rrsize = 0
> allocSize = 16
> r = 0x2b78aee04f00
> old_info = { = { = {_vptr.ForceVFPTToTop 
> = 0x7f3630}, m_refcount = 0}, iobuffer_index = 0, 
>   key = 47797242059264, app = {allotment = {application1 = 5326300, 
> application2 = 0}, http_data = {http_version = 4, 
>   pipeline_max = 59, keepalive_timeout = 17, fail_count = 81, 
> unused1 = 0, last_failure = 0}, rr = {offset = 5326300}}, data = {
> ip = {sa = {sa_family = 54488, sa_data = 
> "^\000\000\000\000\000\020\034$\274x+\000"}, sin = {sin_family = 54488, 
> sin_port = 94, 
> sin_addr = {s_addr = 0}, sin_zero = "\020\034$\274x+\000"}, 
> sin6 = {sin6_family = 54488, sin6_port = 94, sin6_flowinfo = 0, 
> sin6_addr = {__in6_u = {__u6_addr8 = 
> "\020\034$\274x+\000\000\030\036$\274\375\b\000", __u6_addr16 = {7184, 48164, 
> 11128, 
>   0, 7704, 48164, 2301, 0}, __u6_addr32 = {3156483088, 
> 11128, 3156483608, 2301}}}, sin6_scope_id = 3156478176}}, 
> hostname_offset = 6214872, srv = {srv_offset = 54488, srv_weight 
> = 94, srv_priority = 0, srv_port = 0, key = 3156483088}}, 
>   hostname_offset = 11128, ip_timestamp = 2845989456, 
> ip_timeout_interval = 11128, is_srv = 0, reverse_dns = 0, round_robin = 1, 
>   round_robin_elt = 0}
> valid_records = 0
> tip = {_family = 2, _addr = {_ip4 = 540420056, _ip6 = {__in6_u = 
> {__u6_addr8 = "\330'6 x+\000\000\360L\020\250x+\000", 
> __u6_addr16 = {10200, 8246, 11128, 0, 19696, 43024, 11128, 
> 0}, __u6_addr32 = {540420056, 11128, 2819640560, 11128}}}, 
> _byte = "\330'6 x+\000\000\360L\020\250x+\000", _u32 = 
> {540420056, 11128, 2819640560, 11128}, _u64 = {47794936489944, 
>   47797215710448}}}
> ttl_seconds = 132
> aname = 0x2b7938021000 "fbmm1.zenfs.com"
> offset = 96
> thread = 0x2b78a8101010
> __func__ = "dnsEvent"
> #7  0x005145dc in Continuation::handleEvent 

[GitHub] trafficserver issue #1088: TS-4915: Crash from hostdb in PriorityQueueLess

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1088
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/991/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1088: TS-4915: Crash from hostdb in PriorityQueueLess

[shinrich]

Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/1088
  
Squashed and rebased.   Assuming all looks good with merge in the morning.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4915) Crash from hostdb in PriorityQueueLess

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4915?focusedWorklogId=30558=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30558
 ]

ASF GitHub Bot logged work on TS-4915:
--

Author: ASF GitHub Bot
Created on: 13/Oct/16 01:30
Start Date: 13/Oct/16 01:30
Worklog Time Spent: 10m 
  Work Description: Github user shinrich commented on the issue:

https://github.com/apache/trafficserver/pull/1088
  
Squashed and rebased.   Assuming all looks good with merge in the morning.


Issue Time Tracking
---

Worklog Id: (was: 30558)
Time Spent: 5h  (was: 4h 50m)

> Crash from hostdb in PriorityQueueLess
> --
>
> Key: TS-4915
> URL: https://issues.apache.org/jira/browse/TS-4915
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HostDB
>Reporter: Susan Hinrichs
>Priority: Blocker
> Fix For: 7.1.0
>
> Attachments: ts-4915.diff, ts-4915.diff
>
>  Time Spent: 5h
>  Remaining Estimate: 0h
>
> Saw this while testing fix for TS-4813 with debug enabled.
> {code}
> (gdb) bt full
> #0  0x00547bfe in RefCountCacheHashEntry::operator< (this=0x1cc0880, 
> v2=...) at ../iocore/hostdb/P_RefCountCache.h:94
> No locals.
> #1  0x0054988d in 
> PriorityQueueLess::operator() (this=0x2b78a9a2587b, 
> a=@0x2b78f402af68, b=@0x2b78f402aa28)
> at ../lib/ts/PriorityQueue.h:41
> No locals.
> #2  0x00549785 in PriorityQueue PriorityQueueLess >::_bubble_up (this=0x1cb2990, 
> index=2) at ../lib/ts/PriorityQueue.h:191
> comp = {}
> parent = 0
> #3  0x006ecfcc in PriorityQueue PriorityQueueLess >::push (this=0x1cb2990, 
> entry=0x2b78f402af60) at ../../lib/ts/PriorityQueue.h:91
> len = 2
> #4  0x006ec206 in RefCountCachePartition::put 
> (this=0x1cb2900, key=6912554662447498853, item=0x2b78aee04f00, size=96, 
> expire_time=1475202356) at ./P_RefCountCache.h:210
> expiry_entry = 0x2b78f402af60
> __func__ = "put"
> val = 0x1cc0880
> #5  0x006eb3de in RefCountCache::put (this=0x18051e0, 
> key=6912554662447498853, item=0x2b78aee04f00, size=16, 
> expiry_time=1475202356) at ./P_RefCountCache.h:462
> No locals.
> #6  0x006e2d8e in HostDBContinuation::dnsEvent (this=0x2b7938020f00, 
> event=600, e=0x2b78ac009440) at HostDB.cc:1422
> is_rr = false
> old_rr_data = 0x0
> first_record = 0x2b78ac0094f8
> m = 0x1
> failed = false
> old_r = {m_ptr = 0x0}
> af = 2 '\002'
> s_size = 16
> rrsize = 0
> allocSize = 16
> r = 0x2b78aee04f00
> old_info = { = { = {_vptr.ForceVFPTToTop 
> = 0x7f3630}, m_refcount = 0}, iobuffer_index = 0, 
>   key = 47797242059264, app = {allotment = {application1 = 5326300, 
> application2 = 0}, http_data = {http_version = 4, 
>   pipeline_max = 59, keepalive_timeout = 17, fail_count = 81, 
> unused1 = 0, last_failure = 0}, rr = {offset = 5326300}}, data = {
> ip = {sa = {sa_family = 54488, sa_data = 
> "^\000\000\000\000\000\020\034$\274x+\000"}, sin = {sin_family = 54488, 
> sin_port = 94, 
> sin_addr = {s_addr = 0}, sin_zero = "\020\034$\274x+\000"}, 
> sin6 = {sin6_family = 54488, sin6_port = 94, sin6_flowinfo = 0, 
> sin6_addr = {__in6_u = {__u6_addr8 = 
> "\020\034$\274x+\000\000\030\036$\274\375\b\000", __u6_addr16 = {7184, 48164, 
> 11128, 
>   0, 7704, 48164, 2301, 0}, __u6_addr32 = {3156483088, 
> 11128, 3156483608, 2301}}}, sin6_scope_id = 3156478176}}, 
> hostname_offset = 6214872, srv = {srv_offset = 54488, srv_weight 
> = 94, srv_priority = 0, srv_port = 0, key = 3156483088}}, 
>   hostname_offset = 11128, ip_timestamp = 2845989456, 
> ip_timeout_interval = 11128, is_srv = 0, reverse_dns = 0, round_robin = 1, 
>   round_robin_elt = 0}
> valid_records = 0
> tip = {_family = 2, _addr = {_ip4 = 540420056, _ip6 = {__in6_u = 
> {__u6_addr8 = "\330'6 x+\000\000\360L\020\250x+\000", 
> __u6_addr16 = {10200, 8246, 11128, 0, 19696, 43024, 11128, 
> 0}, __u6_addr32 = {540420056, 11128, 2819640560, 11128}}}, 
> _byte = "\330'6 x+\000\000\360L\020\250x+\000", _u32 = 
> {540420056, 11128, 2819640560, 11128}, _u64 = {47794936489944, 
>   47797215710448}}}
> ttl_seconds = 132
> aname = 0x2b7938021000 "fbmm1.zenfs.com"
> offset = 96
> thread = 0x2b78a8101010
> __func__ = "dnsEvent"
> #7  0x005145dc in Continuation::handleEvent (this=0x2b7938020f00, 
> event=600, data=0x2b78ac009440)
>  

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4916?focusedWorklogId=30557=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30557
 ]

ASF GitHub Bot logged work on TS-4916:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 23:38
Start Date: 12/Oct/16 23:38
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/882/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30557)
Time Spent: 2h 50m  (was: 2h 40m)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> next=0x2aaac05d8900
> prev=(nil)
> --- count=1 ---
> id=27
> 

[GitHub] trafficserver issue #1100: TS-4916: Fix for an H2-infinite-loop deadlock

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/882/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4916?focusedWorklogId=30556=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30556
 ]

ASF GitHub Bot logged work on TS-4916:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 23:35
Start Date: 12/Oct/16 23:35
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/990/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30556)
Time Spent: 2h 40m  (was: 2.5h)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 2h 40m
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> next=0x2aaac05d8900
> prev=(nil)
> --- count=1 ---
> id=27
> 

[GitHub] trafficserver issue #1100: TS-4916: Fix for an H2-infinite-loop deadlock

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/990/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Build failed in Jenkins: clang-analyzer #2699

[jenkins]

See 

Changes:

[Leif Hedstrom] TS-4959: Remove remnants of an old browser

[Leif Hedstrom] TS-4959: Remove remnants of an configuration / UA

[Leif Hedstrom] TS-4949: Disables the fuzzy revalidation logic by default

--
[...truncated 5404 lines...]
reading sources... [ 69%] developer-guide/api/functions/TSVIOMutexGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONBytesGet.en
reading sources... [ 69%] developer-guide/api/functions/TSVIONBytesSet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONDoneGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONDoneSet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIONTodoGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReaderGet.en
reading sources... [ 70%] developer-guide/api/functions/TSVIOReenable.en
reading sources... [ 71%] developer-guide/api/functions/TSVIOVConnGet.en
reading sources... [ 71%] developer-guide/api/functions/TSfclose.en
reading sources... [ 71%] developer-guide/api/functions/TSfflush.en
reading sources... [ 71%] developer-guide/api/functions/TSfgets.en
reading sources... [ 71%] developer-guide/api/functions/TSfopen.en
reading sources... [ 72%] developer-guide/api/functions/TSfread.en
reading sources... [ 72%] developer-guide/api/functions/TSfwrite.en
reading sources... [ 72%] developer-guide/api/functions/TSmalloc.en
reading sources... [ 72%] developer-guide/api/functions/index.en
reading sources... [ 73%] developer-guide/api/index.en
reading sources... [ 73%] developer-guide/api/types/TSCacheDataType.en
reading sources... [ 73%] developer-guide/api/types/TSCacheError.en
reading sources... [ 73%] developer-guide/api/types/TSCacheLookupResult.en
reading sources... [ 73%] developer-guide/api/types/TSCacheScanResult.en
reading sources... [ 74%] developer-guide/api/types/TSEvent.en
reading sources... [ 74%] developer-guide/api/types/TSFetchWakeUpOptions.en
reading sources... [ 74%] developer-guide/api/types/TSHttpHookID.en
reading sources... [ 74%] developer-guide/api/types/TSHttpStatus.en
reading sources... [ 75%] developer-guide/api/types/TSHttpType.en
reading sources... [ 75%] developer-guide/api/types/TSIOBuffersSizeIndex.en
reading sources... [ 75%] developer-guide/api/types/TSLifecycleHookID.en
reading sources... [ 75%] developer-guide/api/types/TSLookingUpType.en
reading sources... [ 75%] developer-guide/api/types/TSMilestonesType.en
reading sources... [ 76%] developer-guide/api/types/TSOverridableConfigKey.en
reading sources... [ 76%] developer-guide/api/types/TSParseResult.en
reading sources... [ 76%] developer-guide/api/types/TSRecordAccessType.en
reading sources... [ 76%] developer-guide/api/types/TSRecordCheckType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordDataType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordModeType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordPersistType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordType.en
reading sources... [ 77%] developer-guide/api/types/TSRecordUpdateType.en
reading sources... [ 78%] developer-guide/api/types/TSReturnCode.en
reading sources... [ 78%] developer-guide/api/types/TSSDKVersion.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingMatchType.en
reading sources... [ 78%] 
developer-guide/api/types/TSServerSessionSharingPoolType.en
reading sources... [ 78%] developer-guide/api/types/TSServerState.en
reading sources... [ 79%] developer-guide/api/types/TSStatPeristence.en
reading sources... [ 79%] developer-guide/api/types/TSStatSync.en
reading sources... [ 79%] developer-guide/api/types/TSThreadPool.en
reading sources... [ 79%] developer-guide/api/types/TSUuid.en
reading sources... [ 80%] developer-guide/api/types/TSVConnCloseFlags.en
reading sources... [ 80%] developer-guide/api/types/index.en
reading sources... [ 80%] developer-guide/architecture/api-functions.en
reading sources... [ 80%] developer-guide/architecture/architecture.en
reading sources... [ 80%] developer-guide/architecture/consistency.en
reading sources... [ 81%] developer-guide/architecture/data-structures.en
reading sources... [ 81%] developer-guide/architecture/index.en
reading sources... [ 81%] developer-guide/architecture/ram-cache.en
reading sources... [ 81%] developer-guide/architecture/tiered-storage.en
reading sources... [ 82%] developer-guide/config-vars.en
reading sources... [ 82%] developer-guide/continuous-integration/index.en
reading sources... [ 82%] developer-guide/contributing/index.en
reading sources... [ 82%] developer-guide/debugging/core-dump-analysis.en
reading sources... [ 82%] developer-guide/debugging/debug-builds.en
reading sources... [ 83%] developer-guide/debugging/debug-tags.en
reading sources... [ 83%] developer-guide/debugging/index.en
reading sources... [ 83%] developer-guide/debugging/memory-leaks.en

Jenkins build is back to normal : centos_7-master » gcc,centos_7,debug #2055

[jenkins]

See 

[jira] [Updated] (TS-4905) Crash when slow logging is enabled.

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4905:
---
Backport to Version: 6.2.1  (was: 6.2.1, 7.0.0)

> Crash when slow logging is enabled.
> ---
>
> Key: TS-4905
> URL: https://issues.apache.org/jira/browse/TS-4905
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Peach
>Assignee: Masaori Koshiba
>Priority: Blocker
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> {noformat}
> Thread 14158, [ET_NET 5]:
> 00x004ad342 crash_logger_invoke(int, siginfo_t*, void*) + 0x72
> 10x2abccff59330 __restore_rt + (nil)
> 20x004f166c ProxyClientTransaction::get_netvc() const + 0xc
> 30x005a1712 HttpSM::update_stats() + 0x322
> 40x005b4350 HttpSM::kill_this() + 0x380
> 50x005b4ee8 HttpSM::main_handler(int, void*) + 0x108
> 60x005f174d HttpTunnel::main_handler(int, void*) + 0x19d
> 70x004ea7e2 PluginVC::process_write_side(bool) + 0x572
> 80x004ed1b9 PluginVC::main_handler(int, void*) + 0x3a9
> 90x0076ced0 EThread::process_event(Event*, int) + 0x120
> 10   0x0076db8b EThread::execute() + 0x7fb
> 11   0x0076c95a spawn_thread_internal(void*) + 0x4a
> 12   0x2abccff51184 start_thread + 0xc4
> 13   0x2abcd0c8537d clone + 0x6d
> 14   0x 0x0 + 0x6d
> {noformat}
> In my build (close to master), this happens every time I enable slow logging.



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

[jira] [Updated] (TS-4905) Crash when slow logging is enabled.

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4905:
---
Fix Version/s: (was: 7.1.0)
   7.0.0

> Crash when slow logging is enabled.
> ---
>
> Key: TS-4905
> URL: https://issues.apache.org/jira/browse/TS-4905
> Project: Traffic Server
>  Issue Type: Bug
>Reporter: James Peach
>Assignee: Masaori Koshiba
>Priority: Blocker
> Fix For: 7.0.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> {noformat}
> Thread 14158, [ET_NET 5]:
> 00x004ad342 crash_logger_invoke(int, siginfo_t*, void*) + 0x72
> 10x2abccff59330 __restore_rt + (nil)
> 20x004f166c ProxyClientTransaction::get_netvc() const + 0xc
> 30x005a1712 HttpSM::update_stats() + 0x322
> 40x005b4350 HttpSM::kill_this() + 0x380
> 50x005b4ee8 HttpSM::main_handler(int, void*) + 0x108
> 60x005f174d HttpTunnel::main_handler(int, void*) + 0x19d
> 70x004ea7e2 PluginVC::process_write_side(bool) + 0x572
> 80x004ed1b9 PluginVC::main_handler(int, void*) + 0x3a9
> 90x0076ced0 EThread::process_event(Event*, int) + 0x120
> 10   0x0076db8b EThread::execute() + 0x7fb
> 11   0x0076c95a spawn_thread_internal(void*) + 0x4a
> 12   0x2abccff51184 start_thread + 0xc4
> 13   0x2abcd0c8537d clone + 0x6d
> 14   0x 0x0 + 0x6d
> {noformat}
> In my build (close to master), this happens every time I enable slow logging.



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

[jira] [Updated] (TS-4884) Remove a few unused variables/define in EThread

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4884:
---
Backport to Version:   (was: 7.0.0)

> Remove a few unused variables/define in EThread
> ---
>
> Key: TS-4884
> URL: https://issues.apache.org/jira/browse/TS-4884
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Masato Gosui
>Assignee: Phil Sorber
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> EThread has variable accept_event and main_accept_index, which are unused.
> Also MAX_ACCEPT_EVENTS is not used other than the declaration of accept_event.
> We should be able to remove them without any side effects.
> Looks like these are remnants of old code cleanup.
> https://github.com/apache/trafficserver/commit/0a0c90dd94fd53a0cf9617f945e4e7d9fe42c7a9



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

[jira] [Resolved] (TS-4959) Remove an old remnant of MSIE UA detection

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom resolved TS-4959.
---
Resolution: Fixed

> Remove an old remnant of MSIE UA detection
> --
>
> Key: TS-4959
> URL: https://issues.apache.org/jira/browse/TS-4959
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> This might have been part of an old option as well, that seems to have been 
> removed (so this code was likely left around by mistake).



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

[jira] [Updated] (TS-4884) Remove a few unused variables/define in EThread

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4884:
---
Fix Version/s: (was: 7.1.0)
   7.0.0

> Remove a few unused variables/define in EThread
> ---
>
> Key: TS-4884
> URL: https://issues.apache.org/jira/browse/TS-4884
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Masato Gosui
>Assignee: Phil Sorber
> Fix For: 7.0.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> EThread has variable accept_event and main_accept_index, which are unused.
> Also MAX_ACCEPT_EVENTS is not used other than the declaration of accept_event.
> We should be able to remove them without any side effects.
> Looks like these are remnants of old code cleanup.
> https://github.com/apache/trafficserver/commit/0a0c90dd94fd53a0cf9617f945e4e7d9fe42c7a9



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

[jira] [Work logged] (TS-4949) Disable fuzzy revalidation logic

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4949?focusedWorklogId=30555=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30555
 ]

ASF GitHub Bot logged work on TS-4949:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 22:54
Start Date: 12/Oct/16 22:54
Worklog Time Spent: 10m 
  Work Description: Github user zwoop closed the pull request at:

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


Issue Time Tracking
---

Worklog Id: (was: 30555)
Time Spent: 50m  (was: 40m)

> Disable fuzzy revalidation logic
> 
>
> Key: TS-4949
> URL: https://issues.apache.org/jira/browse/TS-4949
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> In TS-4235, we marked the fuzzy logic as deprecated, but we left it on by 
> default. For 7.0.0, I'd like to disable the configuration defaults entirely, 
> and later for 8.0.0 we remove the remaining code.



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

[jira] [Resolved] (TS-4949) Disable fuzzy revalidation logic

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom resolved TS-4949.
---
Resolution: Fixed

> Disable fuzzy revalidation logic
> 
>
> Key: TS-4949
> URL: https://issues.apache.org/jira/browse/TS-4949
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> In TS-4235, we marked the fuzzy logic as deprecated, but we left it on by 
> default. For 7.0.0, I'd like to disable the configuration defaults entirely, 
> and later for 8.0.0 we remove the remaining code.



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

[GitHub] trafficserver pull request #1090: TS-4949: Disables the fuzzy revalidation l...

[zwoop]

Github user zwoop closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4959) Remove an old remnant of MSIE UA detection

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4959?focusedWorklogId=30554=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30554
 ]

ASF GitHub Bot logged work on TS-4959:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 22:52
Start Date: 12/Oct/16 22:52
Worklog Time Spent: 10m 
  Work Description: Github user zwoop closed the pull request at:

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


Issue Time Tracking
---

Worklog Id: (was: 30554)
Time Spent: 1h 20m  (was: 1h 10m)

> Remove an old remnant of MSIE UA detection
> --
>
> Key: TS-4959
> URL: https://issues.apache.org/jira/browse/TS-4959
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> This might have been part of an old option as well, that seems to have been 
> removed (so this code was likely left around by mistake).



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

[GitHub] trafficserver pull request #1101: TS-4959: Remove remnants of old UA configu...

[zwoop]

Github user zwoop closed the pull request at:

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


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4963) Option to allow keepalive for PluginVC.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4963?focusedWorklogId=30553=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30553
 ]

ASF GitHub Bot logged work on TS-4963:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 22:47
Start Date: 12/Oct/16 22:47
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1102
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/989/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30553)
Time Spent: 0.5h  (was: 20m)

> Option to allow keepalive for PluginVC.
> ---
>
> Key: TS-4963
> URL: https://issues.apache.org/jira/browse/TS-4963
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core, Plugins
>Reporter: James Peach
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> Since it will take some time to explore and test a fix for TS-4960, add a 
> configuration knob to allow keepalive on internal connections.



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

[GitHub] trafficserver issue #1102: TS-4963: Add option to obey keepalive on internal...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1102
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/989/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4963) Option to allow keepalive for PluginVC.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4963?focusedWorklogId=30552=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30552
 ]

ASF GitHub Bot logged work on TS-4963:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 22:44
Start Date: 12/Oct/16 22:44
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1102
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/881/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30552)
Time Spent: 20m  (was: 10m)

> Option to allow keepalive for PluginVC.
> ---
>
> Key: TS-4963
> URL: https://issues.apache.org/jira/browse/TS-4963
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core, Plugins
>Reporter: James Peach
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> Since it will take some time to explore and test a fix for TS-4960, add a 
> configuration knob to allow keepalive on internal connections.



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

[GitHub] trafficserver issue #1102: TS-4963: Add option to obey keepalive on internal...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1102
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/881/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4959) Remove an old remnant of MSIE UA detection

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4959?focusedWorklogId=30551=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30551
 ]

ASF GitHub Bot logged work on TS-4959:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 22:32
Start Date: 12/Oct/16 22:32
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1101
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/880/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30551)
Time Spent: 1h 10m  (was: 1h)

> Remove an old remnant of MSIE UA detection
> --
>
> Key: TS-4959
> URL: https://issues.apache.org/jira/browse/TS-4959
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> This might have been part of an old option as well, that seems to have been 
> removed (so this code was likely left around by mistake).



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

[jira] [Work logged] (TS-4963) Option to allow keepalive for PluginVC.

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4963?focusedWorklogId=30548=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30548
 ]

ASF GitHub Bot logged work on TS-4963:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 22:31
Start Date: 12/Oct/16 22:31
Worklog Time Spent: 10m 
  Work Description: GitHub user jpeach opened a pull request:

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

TS-4963: Add option to obey keepalive on internal transactions.

Add the proxy.config.http.parse.allow_non_http configuration option
to obey the keepalive state on internal transactions. This should be
considered an interim measure until the problems around event delivery
on half-closed internal sessions are investigated.

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

$ git pull https://github.com/jpeach/trafficserver fix/4963

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

https://github.com/apache/trafficserver/pull/1102.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 #1102


commit fcb925b55957de2ba9b21058e137e2fc4e4bfd70
Author: James Peach 
Date:   2016-10-12T22:28:27Z

TS-4963: Add option to obey keepalive on internal transactions.

Add the proxy.config.http.parse.allow_non_http configuration option
to obey the keepalive state on internal transactions. This should be
considered an interim measure until the problems around event delivery
on half-closed internal sessions are investigated.




Issue Time Tracking
---

Worklog Id: (was: 30548)
Time Spent: 10m
Remaining Estimate: 0h

> Option to allow keepalive for PluginVC.
> ---
>
> Key: TS-4963
> URL: https://issues.apache.org/jira/browse/TS-4963
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core, Plugins
>Reporter: James Peach
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> Since it will take some time to explore and test a fix for TS-4960, add a 
> configuration knob to allow keepalive on internal connections.



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

[GitHub] trafficserver pull request #1102: TS-4963: Add option to obey keepalive on i...

[jpeach]

GitHub user jpeach opened a pull request:

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

TS-4963: Add option to obey keepalive on internal transactions.

Add the proxy.config.http.parse.allow_non_http configuration option
to obey the keepalive state on internal transactions. This should be
considered an interim measure until the problems around event delivery
on half-closed internal sessions are investigated.

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

$ git pull https://github.com/jpeach/trafficserver fix/4963

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

https://github.com/apache/trafficserver/pull/1102.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 #1102


commit fcb925b55957de2ba9b21058e137e2fc4e4bfd70
Author: James Peach 
Date:   2016-10-12T22:28:27Z

TS-4963: Add option to obey keepalive on internal transactions.

Add the proxy.config.http.parse.allow_non_http configuration option
to obey the keepalive state on internal transactions. This should be
considered an interim measure until the problems around event delivery
on half-closed internal sessions are investigated.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1101: TS-4959: Remove remnants of old UA configurations...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1101
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/880/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-4735) Possible deadlock on traffic_server startup

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4735:
---
Fix Version/s: (was: 7.1.0)
   7.0.0

> Possible deadlock on traffic_server startup
> ---
>
> Key: TS-4735
> URL: https://issues.apache.org/jira/browse/TS-4735
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
>Assignee: Shrihari
> Fix For: 7.0.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> As part of startup, traffic_server creates two threads (to begin with).
> 1. (main) Thread (1) blocks till its signaled by another thread
> 1. Thread 2 polls for messages from traffic_manager
> It is waiting for a message from traffic_manager which contains all the 
> configuration required for it to go ahead with initialization. Hence, it is 
> critical that the main Thread (1) wait till it gets the configuration.
> Thread 2 which polls for message from traffic_manager works like this:
> {noformat}
> for(;;) {
>   if (pmgmt->require_lm) { <--- Always True (when using traffic_cop)
> pmgmt->pollLMConnection();  <--- | for (count = 0; count < 1; count 
> ++) 
>|   num = 
> mgmt_read_timeout(...) < Blocking call. returns 0 if nothing was received 
> for 1 second
>|   if !num: break 
> <--- Break out of the loop and return from function 
>|   else: 
> read(fd), add_to_event_queue, continue the loop, 
>| Back to fetching 
> another message
>   }
>   pmgmt->processEventQueue();  <--  Process the messages received in 
> pollLMConnection()
>   pmgmt->processSignalQueue();
>   mgmt_sleep_sec(pmgmt->timeout); 
> }
> {noformat}
> RCA:
> There are two problems here:
> 1. If we look into the above code, we should observe that the 
> pollLMConnection might not return back for a very long time if it keeps 
> getting messages. As a result, we may not call processEventQueue() which 
> processes the received messages. And unless we process the messages, we 
> cannot signal the main Thread (1) to continue, which is still blocked. Hence 
> we see the issue where traffic_server won't complete initialization for a 
> very long time.
> 2. The second problem is that why is traffic_server receiving so many 
> messages at boot-up? The problem lies in the configuration. In 6.2.x, we 
> replaced 
> 'proxy.process.ssl.total_success_handshake_count' with 
> 'proxy.process.ssl.total_success_handshake_count_in'. 
> In order to provide backwards compatibility, we defined the old stat in 
> stats.config.xml. The caveat here is that, since this statconfig is defined 
> in stats.config.xml, traffic_manager assumes the responsibility of updating 
> this stat. According to the code:
> {noformat}
> if (i_am_not_owner_of(stat)) : send traffic_server a notify message.
> {noformat}
> Ideally, this code should not be triggered because, traffic_manager does own 
> the stat. However, the ownership in the code is determined solely based on 
> the 'string name'. If the name contains 'process', it is owned by 
> traffic_server. This leads to an interesting scenario where traffic_manger 
> keeps updating its own stat and sends unnecessary events to traffic_server. 
> These updates happen every 1 second (Thanks James for helping me understand 
> this period) which is the same as our timeout in traffic_server.  Due to 
> 'Problem 1' we can prevent traffic_server from processing any messages for up 
> to 10,000 seconds! (Just imagine the case where the message is received just 
> before the timout of 1 second happens)
> I saw this happening with 100% on a VM but 0% on a physical box. I don't have 
> any other results as of now though.



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

[jira] [Updated] (TS-4558) ASAN buffer overflow in traffic_manager -h

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4558:
---
Backport to Version:   (was: 7.0.0)

> ASAN buffer overflow in traffic_manager -h
> --
>
> Key: TS-4558
> URL: https://issues.apache.org/jira/browse/TS-4558
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Leif Hedstrom
>Assignee: Steven Feltner
>  Labels: ASAN
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> {code}
> [root@qa1 ats]# ./bin/traffic_manager  -h
> Usage: traffic_manager [--SWITCH [ARG]]
>   switch__type__default___description
>   --proxyOff  on   
> =
> ==14425==ERROR: AddressSanitizer: global-buffer-overflow on address 
> 0x0089fd40 at pc 0x7fd0aef80b5e bp 0x7ffe0d210590 sp 0x7ffe0d210588
> READ of size 4 at 0x0089fd40 thread T0
> #0 0x7fd0aef80b5d in usage(ArgumentDescription const*, unsigned int, char 
> const*) /usr/local/src/trafficserver/lib/ts/ink_args.cc:323
> #1 0x7fd0aef7f5c7 in process_arg 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:122
> #2 0x7fd0aef80135 in process_args_ex(AppVersionInfo const*, 
> ArgumentDescription const*, unsigned int, char const**) 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:237
> #3 0x7fd0aef80bba in process_args(AppVersionInfo const*, 
> ArgumentDescription const*, unsigned int, char const**, char const*) 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:166
> #4 0x4305a4 in main 
> /usr/local/src/trafficserver/cmd/traffic_manager/traffic_manager.cc:481
> #5 0x7fd0abbfdb14 in __libc_start_main (/lib64/libc.so.6+0x21b14)
> #6 0x4343e4  (/opt/ats/bin/traffic_manager+0x4343e4)
> 0x0089fd41 is located 0 bytes to the right of global variable 'proxy_off' 
> defined in 'traffic_manager.cc:86:13' (0x89fd40) of size 1
>   'proxy_off' is ascii string ''
> SUMMARY: AddressSanitizer: global-buffer-overflow 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:323 usage(ArgumentDescription 
> const*, unsigned int, char const*)
> Shadow bytes around the buggy address:
>   0x8010bf50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf60: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x8010bfa0: 00 00 00 00 f9 f9 f9 f9[01]f9 f9 f9 f9 f9 f9 f9
>   0x8010bfb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bfc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bfd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bfe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:   00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:   fa
>   Heap right redzone:  fb
>   Freed heap region:   fd
>   Stack left redzone:  f1
>   Stack mid redzone:   f2
>   Stack right redzone: f3
>   Stack partial redzone:   f4
>   Stack after return:  f5
>   Stack use after scope:   f8
>   Global redzone:  f9
>   Global init order:   f6
>   Poisoned by user:f7
>   Container overflow:  fc
>   Array cookie:ac
>   Intra object redzone:bb
>   ASan internal:   fe
> ==14425==ABORTING
> {code}



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

[jira] [Updated] (TS-4735) Possible deadlock on traffic_server startup

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4735:
---
Backport to Version:   (was: 7.0.0)

> Possible deadlock on traffic_server startup
> ---
>
> Key: TS-4735
> URL: https://issues.apache.org/jira/browse/TS-4735
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.2.0
>Reporter: Shrihari
>Assignee: Shrihari
> Fix For: 7.0.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> As part of startup, traffic_server creates two threads (to begin with).
> 1. (main) Thread (1) blocks till its signaled by another thread
> 1. Thread 2 polls for messages from traffic_manager
> It is waiting for a message from traffic_manager which contains all the 
> configuration required for it to go ahead with initialization. Hence, it is 
> critical that the main Thread (1) wait till it gets the configuration.
> Thread 2 which polls for message from traffic_manager works like this:
> {noformat}
> for(;;) {
>   if (pmgmt->require_lm) { <--- Always True (when using traffic_cop)
> pmgmt->pollLMConnection();  <--- | for (count = 0; count < 1; count 
> ++) 
>|   num = 
> mgmt_read_timeout(...) < Blocking call. returns 0 if nothing was received 
> for 1 second
>|   if !num: break 
> <--- Break out of the loop and return from function 
>|   else: 
> read(fd), add_to_event_queue, continue the loop, 
>| Back to fetching 
> another message
>   }
>   pmgmt->processEventQueue();  <--  Process the messages received in 
> pollLMConnection()
>   pmgmt->processSignalQueue();
>   mgmt_sleep_sec(pmgmt->timeout); 
> }
> {noformat}
> RCA:
> There are two problems here:
> 1. If we look into the above code, we should observe that the 
> pollLMConnection might not return back for a very long time if it keeps 
> getting messages. As a result, we may not call processEventQueue() which 
> processes the received messages. And unless we process the messages, we 
> cannot signal the main Thread (1) to continue, which is still blocked. Hence 
> we see the issue where traffic_server won't complete initialization for a 
> very long time.
> 2. The second problem is that why is traffic_server receiving so many 
> messages at boot-up? The problem lies in the configuration. In 6.2.x, we 
> replaced 
> 'proxy.process.ssl.total_success_handshake_count' with 
> 'proxy.process.ssl.total_success_handshake_count_in'. 
> In order to provide backwards compatibility, we defined the old stat in 
> stats.config.xml. The caveat here is that, since this statconfig is defined 
> in stats.config.xml, traffic_manager assumes the responsibility of updating 
> this stat. According to the code:
> {noformat}
> if (i_am_not_owner_of(stat)) : send traffic_server a notify message.
> {noformat}
> Ideally, this code should not be triggered because, traffic_manager does own 
> the stat. However, the ownership in the code is determined solely based on 
> the 'string name'. If the name contains 'process', it is owned by 
> traffic_server. This leads to an interesting scenario where traffic_manger 
> keeps updating its own stat and sends unnecessary events to traffic_server. 
> These updates happen every 1 second (Thanks James for helping me understand 
> this period) which is the same as our timeout in traffic_server.  Due to 
> 'Problem 1' we can prevent traffic_server from processing any messages for up 
> to 10,000 seconds! (Just imagine the case where the message is received just 
> before the timout of 1 second happens)
> I saw this happening with 100% on a VM but 0% on a physical box. I don't have 
> any other results as of now though.



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

[jira] [Updated] (TS-4558) ASAN buffer overflow in traffic_manager -h

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4558:
---
Fix Version/s: (was: 7.1.0)
   7.0.0

> ASAN buffer overflow in traffic_manager -h
> --
>
> Key: TS-4558
> URL: https://issues.apache.org/jira/browse/TS-4558
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager
>Reporter: Leif Hedstrom
>Assignee: Steven Feltner
>  Labels: ASAN
> Fix For: 7.0.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> {code}
> [root@qa1 ats]# ./bin/traffic_manager  -h
> Usage: traffic_manager [--SWITCH [ARG]]
>   switch__type__default___description
>   --proxyOff  on   
> =
> ==14425==ERROR: AddressSanitizer: global-buffer-overflow on address 
> 0x0089fd40 at pc 0x7fd0aef80b5e bp 0x7ffe0d210590 sp 0x7ffe0d210588
> READ of size 4 at 0x0089fd40 thread T0
> #0 0x7fd0aef80b5d in usage(ArgumentDescription const*, unsigned int, char 
> const*) /usr/local/src/trafficserver/lib/ts/ink_args.cc:323
> #1 0x7fd0aef7f5c7 in process_arg 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:122
> #2 0x7fd0aef80135 in process_args_ex(AppVersionInfo const*, 
> ArgumentDescription const*, unsigned int, char const**) 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:237
> #3 0x7fd0aef80bba in process_args(AppVersionInfo const*, 
> ArgumentDescription const*, unsigned int, char const**, char const*) 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:166
> #4 0x4305a4 in main 
> /usr/local/src/trafficserver/cmd/traffic_manager/traffic_manager.cc:481
> #5 0x7fd0abbfdb14 in __libc_start_main (/lib64/libc.so.6+0x21b14)
> #6 0x4343e4  (/opt/ats/bin/traffic_manager+0x4343e4)
> 0x0089fd41 is located 0 bytes to the right of global variable 'proxy_off' 
> defined in 'traffic_manager.cc:86:13' (0x89fd40) of size 1
>   'proxy_off' is ascii string ''
> SUMMARY: AddressSanitizer: global-buffer-overflow 
> /usr/local/src/trafficserver/lib/ts/ink_args.cc:323 usage(ArgumentDescription 
> const*, unsigned int, char const*)
> Shadow bytes around the buggy address:
>   0x8010bf50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf60: f9 f9 f9 f9 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bf90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> =>0x8010bfa0: 00 00 00 00 f9 f9 f9 f9[01]f9 f9 f9 f9 f9 f9 f9
>   0x8010bfb0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bfc0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bfd0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bfe0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>   0x8010bff0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> Shadow byte legend (one shadow byte represents 8 application bytes):
>   Addressable:   00
>   Partially addressable: 01 02 03 04 05 06 07
>   Heap left redzone:   fa
>   Heap right redzone:  fb
>   Freed heap region:   fd
>   Stack left redzone:  f1
>   Stack mid redzone:   f2
>   Stack right redzone: f3
>   Stack partial redzone:   f4
>   Stack after return:  f5
>   Stack use after scope:   f8
>   Global redzone:  f9
>   Global init order:   f6
>   Poisoned by user:f7
>   Container overflow:  fc
>   Array cookie:ac
>   Intra object redzone:bb
>   ASan internal:   fe
> ==14425==ABORTING
> {code}



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

[jira] [Work logged] (TS-4959) Remove an old remnant of MSIE UA detection

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4959?focusedWorklogId=30547=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30547
 ]

ASF GitHub Bot logged work on TS-4959:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 22:25
Start Date: 12/Oct/16 22:25
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1101
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/988/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30547)
Time Spent: 1h  (was: 50m)

> Remove an old remnant of MSIE UA detection
> --
>
> Key: TS-4959
> URL: https://issues.apache.org/jira/browse/TS-4959
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> This might have been part of an old option as well, that seems to have been 
> removed (so this code was likely left around by mistake).



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

[GitHub] trafficserver issue #1101: TS-4959: Remove remnants of old UA configurations...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1101
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/988/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4916?focusedWorklogId=30546=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30546
 ]

ASF GitHub Bot logged work on TS-4916:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 22:23
Start Date: 12/Oct/16 22:23
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/987/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30546)
Time Spent: 2.5h  (was: 2h 20m)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 2.5h
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> next=0x2aaac05d8900
> prev=(nil)
> --- count=1 ---
> id=27
> 

[GitHub] trafficserver issue #1100: TS-4916: Fix for an H2-infinite-loop deadlock

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/987/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TS-4845) NULL dereference in url_sig

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-4845:


This was in master at the time the 7.0.x branch was created.

> NULL dereference in url_sig
> ---
>
> Key: TS-4845
> URL: https://issues.apache.org/jira/browse/TS-4845
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: James Peach
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Seen in the static analyzer:
> {noformat}
> Making all in url_sig
>   CC   url_sig.lo
> url_sig.c:564:38: warning: Null pointer argument in call to string length 
> function
>   app_qry = getAppQueryString(query, strlen(query));
>  ^
> 1 warning generated.
> {noformat}
> If there is no query string you can still do {{goto allow}}, but it looks 
> like the code assumes missing query string will always {{goto deny}}.



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

[jira] [Updated] (TS-4845) NULL dereference in url_sig

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4845:
---
Fix Version/s: (was: 7.1.0)
   7.0.0

> NULL dereference in url_sig
> ---
>
> Key: TS-4845
> URL: https://issues.apache.org/jira/browse/TS-4845
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: James Peach
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Seen in the static analyzer:
> {noformat}
> Making all in url_sig
>   CC   url_sig.lo
> url_sig.c:564:38: warning: Null pointer argument in call to string length 
> function
>   app_qry = getAppQueryString(query, strlen(query));
>  ^
> 1 warning generated.
> {noformat}
> If there is no query string you can still do {{goto allow}}, but it looks 
> like the code assumes missing query string will always {{goto deny}}.



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

[jira] [Updated] (TS-4845) NULL dereference in url_sig

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4845:
---
Backport to Version: 6.2.1  (was: 6.2.1, 7.0.0)

> NULL dereference in url_sig
> ---
>
> Key: TS-4845
> URL: https://issues.apache.org/jira/browse/TS-4845
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Plugins
>Reporter: James Peach
>Assignee: John Rushford
> Fix For: 7.0.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Seen in the static analyzer:
> {noformat}
> Making all in url_sig
>   CC   url_sig.lo
> url_sig.c:564:38: warning: Null pointer argument in call to string length 
> function
>   app_qry = getAppQueryString(query, strlen(query));
>  ^
> 1 warning generated.
> {noformat}
> If there is no query string you can still do {{goto allow}}, but it looks 
> like the code assumes missing query string will always {{goto deny}}.



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

[GitHub] trafficserver issue #1100: TS-4916: Fix for an H2-infinite-loop deadlock

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/879/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4916?focusedWorklogId=30545=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30545
 ]

ASF GitHub Bot logged work on TS-4916:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 22:13
Start Date: 12/Oct/16 22:13
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/879/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30545)
Time Spent: 2h 20m  (was: 2h 10m)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 2h 20m
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> next=0x2aaac05d8900
> prev=(nil)
> --- count=1 ---
> id=27
> this=0x2aaac05d8900

[jira] [Work logged] (TS-4959) Remove an old remnant of MSIE UA detection

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4959?focusedWorklogId=30543=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30543
 ]

ASF GitHub Bot logged work on TS-4959:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 22:11
Start Date: 12/Oct/16 22:11
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1101
  
Rebuilding again, because I think the trees on the buildbots was busted 
[approve ci].


Issue Time Tracking
---

Worklog Id: (was: 30543)
Time Spent: 50m  (was: 40m)

> Remove an old remnant of MSIE UA detection
> --
>
> Key: TS-4959
> URL: https://issues.apache.org/jira/browse/TS-4959
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 50m
>  Remaining Estimate: 0h
>
> This might have been part of an old option as well, that seems to have been 
> removed (so this code was likely left around by mistake).



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

[GitHub] trafficserver issue #1101: TS-4959: Remove remnants of old UA configurations...

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1101
  
Rebuilding again, because I think the trees on the buildbots was busted 
[approve ci].


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4916?focusedWorklogId=30542=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30542
 ]

ASF GitHub Bot logged work on TS-4916:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 22:06
Start Date: 12/Oct/16 22:06
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
Try again [approve ci].


Issue Time Tracking
---

Worklog Id: (was: 30542)
Time Spent: 2h 10m  (was: 2h)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 2h 10m
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> next=0x2aaac05d8900
> prev=(nil)
> --- count=1 ---
> id=27
> this=0x2aaac05d8900
> next=0x2ae5b6bbec00
> prev=0x2ae673f0c840
> --- count=2 ---
> id=19
> 

[GitHub] trafficserver issue #1100: TS-4916: Fix for an H2-infinite-loop deadlock

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
Try again [approve ci].


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4955) Remove the global mutex from the plugin session acceptor

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4955?focusedWorklogId=30541=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30541
 ]

ASF GitHub Bot logged work on TS-4955:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 22:05
Start Date: 12/Oct/16 22:05
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1096
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/970/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30541)
Time Spent: 1h  (was: 50m)

> Remove the global mutex from the plugin session acceptor
> 
>
> Key: TS-4955
> URL: https://issues.apache.org/jira/browse/TS-4955
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core, Performance
>Reporter: James Peach
>  Time Spent: 1h
>  Remaining Estimate: 0h
>
> {{plugin_http_accept}} has a global mutex which gets contended by protocol 
> plugins. We don't require locking on {{HttpSessionAccept}} objects and the 
> normal server port accept objects are not locked.



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

Build failed in Jenkins: centos_7-master » gcc,centos_7,debug #2054

[jenkins]

See 


--
[...truncated 19111 lines...]
0|0|86.110.4.0|86.110.4.0|per_ip| |F|0|0|1970/01/01 
00:00:00|1888958975128722431|0|0|1|0
0|0|116.92.7.0|116.92.7.0|per_ip| |F|0|0|1970/01/01 
00:00:00|16631009639014254015|0|0|1|0
0|0|144.237.10.0|144.237.10.0|per_ip| |F|0|0|1970/01/01 
00:00:00|12905853032977407679|0|0|1|0
0|0|103.150.5.0|103.150.5.0|per_ip| |F|0|0|1970/01/01 
00:00:00|16572297681063508287|0|0|1|0
0|0|250.74.6.0|250.74.6.0|per_ip| |F|0|0|1970/01/01 
00:00:00|3435544084056601407|0|0|1|0
0|0|33.228.1.0|33.228.1.0|per_ip| |F|0|0|1970/01/01 
00:00:00|7054485740756729087|0|0|1|0
0|0|5.119.12.0|5.119.12.0|per_ip| |F|0|0|1970/01/01 
00:00:00|14495321938049529599|0|0|1|0
0|0|176.81.0.0|176.81.0.0|per_ip| |F|0|0|1970/01/01 
00:00:00|11377479059831779583|0|0|1|0
0|0|156.11.6.0|156.11.6.0|per_ip| |F|0|0|1970/01/01 
00:00:00|8234706063569537663|0|0|1|0
0|0|109.134.9.0|109.134.9.0|per_ip| |F|0|0|1970/01/01 
00:00:00|14050053816847377407|0|0|1|0
0|0|140.42.10.0|140.42.10.0|per_ip| |F|0|0|1970/01/01 
00:00:00|8162434488007175487|0|0|1|0
0|0|114.61.13.0|114.61.13.0|per_ip| |F|0|0|1970/01/01 
00:00:00|3945992723180975743|0|0|1|0
0|0|33.100.6.0|33.100.6.0|per_ip| |F|0|0|1970/01/01 
00:00:00|6825087806830268671|0|0|1|0
0|0|83.94.9.0|83.94.9.0|per_ip| |F|0|0|1970/01/01 
00:00:00|3346846807966173951|0|0|1|0
0|0|145.111.0.0|145.111.0.0|per_ip| |F|0|0|1970/01/01 
00:00:00|4310273191177806975|0|0|1|0
RPRINT Congestion_CongestionDB: There are 1048576 records in the db
RPRINT Congestion_CongestionDB: After test [1] there are 1024 records in the db
RPRINT Congestion_CongestionDB: After test [2] there are 2816 records in the db
RPRINT Congestion_CongestionDB: After test [3] there are 1048576 records in the 
db
REGRESSION_RESULT Congestion_CongestionDB:  PASSED
REGRESSION TEST Congestion_FailHistory started
RPRINT Congestion_FailHistory: Verify the result
RPRINT Congestion_FailHistory: Content of history
RPRINT Congestion_FailHistory: bucket 0 => events 2612 , sum = 2612
RPRINT Congestion_FailHistory: bucket 1 => events 3974 , sum = 6586
RPRINT Congestion_FailHistory: bucket 2 => events 4015 , sum = 10601
RPRINT Congestion_FailHistory: bucket 3 => events 3855 , sum = 14456
RPRINT Congestion_FailHistory: bucket 4 => events 4029 , sum = 18485
RPRINT Congestion_FailHistory: bucket 5 => events 4023 , sum = 22508
RPRINT Congestion_FailHistory: bucket 6 => events 3828 , sum = 26336
RPRINT Congestion_FailHistory: bucket 7 => events 3855 , sum = 30191
RPRINT Congestion_FailHistory: bucket 8 => events 3914 , sum = 34105
RPRINT Congestion_FailHistory: bucket 9 => events 3864 , sum = 37969
RPRINT Congestion_FailHistory: bucket 10 => events 3926 , sum = 41895
RPRINT Congestion_FailHistory: bucket 11 => events 4018 , sum = 45913
RPRINT Congestion_FailHistory: bucket 12 => events 3957 , sum = 49870
RPRINT Congestion_FailHistory: bucket 13 => events 3935 , sum = 53805
RPRINT Congestion_FailHistory: bucket 14 => events 3959 , sum = 57764
RPRINT Congestion_FailHistory: bucket 15 => events 3869 , sum = 61633
RPRINT Congestion_FailHistory: bucket 16 => events 3903 , sum = 65536
Events: 65536, CurIndex: 0, LastEvent: 299, HistLen: 306, BinLen: 18, Start: 0
RPRINT Congestion_FailHistory: 233|0|dummy_host| |per_ip| |F|0|0|1970/01/01 
00:03:53|0|299|65536|1|0
RPRINT Congestion_FailHistory: Verify the result
RPRINT Congestion_FailHistory: Content of history
RPRINT Congestion_FailHistory: bucket 0 => events 961 , sum = 961
RPRINT Congestion_FailHistory: bucket 1 => events 978 , sum = 1939
RPRINT Congestion_FailHistory: bucket 2 => events 602 , sum = 2541
RPRINT Congestion_FailHistory: bucket 3 => events 1011 , sum = 3552
RPRINT Congestion_FailHistory: bucket 4 => events 956 , sum = 4508
RPRINT Congestion_FailHistory: bucket 5 => events 1019 , sum = 5527
RPRINT Congestion_FailHistory: bucket 6 => events 992 , sum = 6519
RPRINT Congestion_FailHistory: bucket 7 => events 969 , sum = 7488
RPRINT Congestion_FailHistory: bucket 8 => events 1009 , sum = 8497
RPRINT Congestion_FailHistory: bucket 9 => events 950 , sum = 9447
RPRINT Congestion_FailHistory: bucket 10 => events 976 , sum = 10423
RPRINT Congestion_FailHistory: bucket 11 => events 974 , sum = 11397
RPRINT Congestion_FailHistory: bucket 12 => events 1007 , sum = 12404
RPRINT Congestion_FailHistory: bucket 13 => events 955 , sum = 13359
RPRINT Congestion_FailHistory: bucket 14 => events 998 , sum = 14357
RPRINT Congestion_FailHistory: bucket 15 => events 983 , sum = 15340
RPRINT Congestion_FailHistory: bucket 16 => events 1044 , sum = 16384
Events: 16384, CurIndex: 2, LastEvent: 2999, HistLen: 306, BinLen: 18, Start: 
2700
RPRINT Congestion_FailHistory: 2997|0|dummy_host| |per_ip| |F|0|0|1970/01/01 
00:49:57|0|2999|16384|1|0
REGRESSION_RESULT Congestion_FailHistory:   PASSED
REGRESSION TEST Congestion_HashTable started

[GitHub] trafficserver issue #1096: TS-4955: Remove the global mutex from the plugin ...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1096
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/970/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-4895) CID 1021743: Uninitialized members in iocore/net/UnixNet.cc

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4895:
---
Backport to Version: 7.0.0
  Fix Version/s: (was: 7.0.0)
 7.1.0

> CID 1021743:  Uninitialized members in iocore/net/UnixNet.cc
> 
>
> Key: TS-4895
> URL: https://issues.apache.org/jira/browse/TS-4895
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Leif Hedstrom
>Assignee: Oknet Xu
>  Labels: coverity
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {code}
> *** CID 1021743:  Uninitialized members  (UNINIT_CTOR)
> /iocore/net/UnixNet.cc: 269 in NetHandler::NetHandler()()
> 263 max_connections_active_in(0),
> 264 inactive_threashold_in(0),
> 265 transaction_no_activity_timeout_in(0),
> 266 keep_alive_no_activity_timeout_in(0)
> 267 {
> 268   SET_HANDLER((NetContHandler)::startNetEvent);
>CID 1021743:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member "default_inactivity_timeout" is not initialized in 
> this constructor nor in any functions that it calls.
> 269 }
> 270 
> 271 int
> 272 update_nethandler_config(const char *name, RecDataT data_type 
> ATS_UNUSED, RecData data, void *cookie)
> 273 {
> 274   NetHandler *nh = static_cast(cookie);
> {code}



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

[jira] [Updated] (TS-4895) CID 1021743: Uninitialized members in iocore/net/UnixNet.cc

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4895:
---
Backport to Version:   (was: 7.0.0)

> CID 1021743:  Uninitialized members in iocore/net/UnixNet.cc
> 
>
> Key: TS-4895
> URL: https://issues.apache.org/jira/browse/TS-4895
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Leif Hedstrom
>Assignee: Oknet Xu
>  Labels: coverity
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {code}
> *** CID 1021743:  Uninitialized members  (UNINIT_CTOR)
> /iocore/net/UnixNet.cc: 269 in NetHandler::NetHandler()()
> 263 max_connections_active_in(0),
> 264 inactive_threashold_in(0),
> 265 transaction_no_activity_timeout_in(0),
> 266 keep_alive_no_activity_timeout_in(0)
> 267 {
> 268   SET_HANDLER((NetContHandler)::startNetEvent);
>CID 1021743:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member "default_inactivity_timeout" is not initialized in 
> this constructor nor in any functions that it calls.
> 269 }
> 270 
> 271 int
> 272 update_nethandler_config(const char *name, RecDataT data_type 
> ATS_UNUSED, RecData data, void *cookie)
> 273 {
> 274   NetHandler *nh = static_cast(cookie);
> {code}



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

[jira] [Updated] (TS-4895) CID 1021743: Uninitialized members in iocore/net/UnixNet.cc

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4895:
---
Fix Version/s: (was: 7.1.0)
   7.0.0

> CID 1021743:  Uninitialized members in iocore/net/UnixNet.cc
> 
>
> Key: TS-4895
> URL: https://issues.apache.org/jira/browse/TS-4895
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Network
>Reporter: Leif Hedstrom
>Assignee: Oknet Xu
>  Labels: coverity
> Fix For: 7.0.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> {code}
> *** CID 1021743:  Uninitialized members  (UNINIT_CTOR)
> /iocore/net/UnixNet.cc: 269 in NetHandler::NetHandler()()
> 263 max_connections_active_in(0),
> 264 inactive_threashold_in(0),
> 265 transaction_no_activity_timeout_in(0),
> 266 keep_alive_no_activity_timeout_in(0)
> 267 {
> 268   SET_HANDLER((NetContHandler)::startNetEvent);
>CID 1021743:  Uninitialized members  (UNINIT_CTOR)
>Non-static class member "default_inactivity_timeout" is not initialized in 
> this constructor nor in any functions that it calls.
> 269 }
> 270 
> 271 int
> 272 update_nethandler_config(const char *name, RecDataT data_type 
> ATS_UNUSED, RecData data, void *cookie)
> 273 {
> 274   NetHandler *nh = static_cast(cookie);
> {code}



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

[jira] [Updated] (TS-4911) ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem)

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4911:
---
Fix Version/s: (was: 7.1.0)
   7.0.0

> ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and 
> write lock error was encountered (thundering herd problem)
> ---
>
> Key: TS-4911
> URL: https://issues.apache.org/jira/browse/TS-4911
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua, Plugins
>Affects Versions: 6.2.1, 7.0.0, 7.1.0
>Reporter: Rajendra Kishore Bonumahanti
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got 
> restarted due to “FATAL: InkAPI.cc:3800: failed assert 
> `sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error 
> was encountered (thundering herd problem). The ATS restart is due to 
> ts.client_response.get_status() function call in 
> TS_LUA_HOOK_SEND_RESPONSE_HDR hook function when re-direct is enabled on 502 
> error.
> == error when ts_lua plugin is used with collapsed_forwarding plugin ==
> map http://testurl.com/ http://origin.com/ @plugin=tslua.so 
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua 
> @plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
> test.lua:
> ===
> function __init__()
>local FUNCTION = '__init__(): '
> ts.debug(FUNCTION .. 'Entering..')
> return 0
> end
> function responseHook()
> local FUNCTION = 'responseHook(): '
> ts.debug(FUNCTION .. 'Entering..')
> local c_code = tostring(ts.client_response.get_status())
> ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
> if string.find(c_code, "^[45]") then
> ts.debug(FUNCTION .. 'client response code is now set to 500')
> ts.client_response.set_status(500)
> end
> return 0
> end
> function do_remap()
> local FUNCTION = 'do_remap(): '
> ts.debug(FUNCTION .. 'Entering..')
> ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
> return 0
> end
> 
> The log…
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State 
> Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] 
> perform_cache_write_action CACE_DO_SERVE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect) 
> is_redirect_required 1
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling 
> plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook(): 
> Entering..
> FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj) 
> == TS_SUCCESS`
> traffic_server: using root directory '/opt/trafficserver'
> validate_filter_args: "action=deny"
> -
> Filter "" status: allow_flag=false, src_ip_valid=false, 
> in_ip_valid=false, internal=false active_queue_flag=0
> standard methods=nonstandard methods=
> src_ip_cnt=0
> in_ip_cnt=0
> URL Rewrite table with 3 entries
>   Reverse Proxy is On
>   Forward Mapping Table with 3 entries
>  http:/// => http://127.0.0.1/  <> [plugins not enabled; running with 
> 0 plugins]
>  http://xx.xx.xx.xx/ => http://xx.xx.xx.xx/  <> [plugins are enabled; 
> running with  plugins]
>  http://testurl.com/ => http://origin.com//  <> [plugins are enabled; 
> running with 2 plugins]
>   Reverse Mapping Table with 0 entries
>   Permanent Redirect Mapping Table with 0 entries
>   Temporary Redirect Mapping Table with 0 entries
>   Forward Mapping With Recv Port Table with 0 entries
>   Referer filter default redirect URL: "http://www.example.com/;
> traffic_server: Aborted (Signal sent by tkill() 129399 99)
> traffic_server - STACK TRACE:
> /opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ab5ee]
> /lib64/libpthread.so.0(+0xf100)[0x2ad67f3eb100]
> /lib64/libc.so.6(gsignal+0x37)[0x2ad6803bb5f7]
> /lib64/libc.so.6(abort+0x148)[0x2ad6803bcce8]
> /opt/trafficserver/lib/libtsutil.so.6(+0x28668)[0x2ad67d927668]
> /opt/trafficserver/lib/libtsutil.so.6(+0x286fc)[0x2ad67d9276fc]
> /opt/trafficserver/lib/libtsutil.so.6(+0x269e5)[0x2ad67d9259e5]
> /opt/trafficserver/bin/traffic_server[0x4c7973]
> /opt/trafficserver/libexec/trafficserver/tslua.so(+0x9aeb)[0x2ad695821aeb]
> /opt/trafficserver/bin/traffic_server[0x5834e6]
> 
> It appears, the 

[jira] [Updated] (TS-4911) ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and write lock error was encountered (thundering herd problem)

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4911:
---
Backport to Version: 6.2.1  (was: 6.2.1, 7.0.0)

> ATS restarts when ts_lua plugin is used with collapsed_forwarding plugin and 
> write lock error was encountered (thundering herd problem)
> ---
>
> Key: TS-4911
> URL: https://issues.apache.org/jira/browse/TS-4911
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Lua, Plugins
>Affects Versions: 6.2.1, 7.0.0, 7.1.0
>Reporter: Rajendra Kishore Bonumahanti
>Assignee: Kit Chan
> Fix For: 7.0.0
>
>  Time Spent: 3h
>  Remaining Estimate: 0h
>
> ATS (ts_lua plugin is used along with collapsed_forwarding plugin) got 
> restarted due to “FATAL: InkAPI.cc:3800: failed assert 
> `sdk_sanity_check_http_hdr_handle(obj) == TS_SUCCESS`” when write lock error 
> was encountered (thundering herd problem). The ATS restart is due to 
> ts.client_response.get_status() function call in 
> TS_LUA_HOOK_SEND_RESPONSE_HDR hook function when re-direct is enabled on 502 
> error.
> == error when ts_lua plugin is used with collapsed_forwarding plugin ==
> map http://testurl.com/ http://origin.com/ @plugin=tslua.so 
> @pparam=/opt/trafficserver/etc/trafficserver/lua/test.lua 
> @plugin=collapsed_forwarding.so @pparam=--delay=10 @pparam=--retries=5
> test.lua:
> ===
> function __init__()
>local FUNCTION = '__init__(): '
> ts.debug(FUNCTION .. 'Entering..')
> return 0
> end
> function responseHook()
> local FUNCTION = 'responseHook(): '
> ts.debug(FUNCTION .. 'Entering..')
> local c_code = tostring(ts.client_response.get_status())
> ts.debug(FUNCTION .. 'Original client_response_code: ' .. c_code)
> if string.find(c_code, "^[45]") then
> ts.debug(FUNCTION .. 'client response code is now set to 500')
> ts.client_response.set_status(500)
> end
> return 0
> end
> function do_remap()
> local FUNCTION = 'do_remap(): '
> ts.debug(FUNCTION .. 'Entering..')
> ts.hook(TS_LUA_HOOK_SEND_RESPONSE_HDR, responseHook)
> return 0
> end
> 
> The log…
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] State 
> Transition: SM_ACTION_AP_CACHE_LOOKUP_COMPLETE -> SM_ACTION_SERVE_FROM_CACHE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] 
> perform_cache_write_action CACE_DO_SERVE
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http_redirect) 
> is_redirect_required 1
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DEBUG: (http) [148] calling 
> plugin on hook TS_HTTPSEND_RESPONSE_HDR_HOOK at hook 0x1832bc0
> [Sep 20 19:53:43.746] Server {0x2ad69673e700} DIAG: (ts_lua) responseHook(): 
> Entering..
> FATAL: InkAPI.cc:3800: failed assert `sdk_sanity_check_http_hdr_handle(obj) 
> == TS_SUCCESS`
> traffic_server: using root directory '/opt/trafficserver'
> validate_filter_args: "action=deny"
> -
> Filter "" status: allow_flag=false, src_ip_valid=false, 
> in_ip_valid=false, internal=false active_queue_flag=0
> standard methods=nonstandard methods=
> src_ip_cnt=0
> in_ip_cnt=0
> URL Rewrite table with 3 entries
>   Reverse Proxy is On
>   Forward Mapping Table with 3 entries
>  http:/// => http://127.0.0.1/  <> [plugins not enabled; running with 
> 0 plugins]
>  http://xx.xx.xx.xx/ => http://xx.xx.xx.xx/  <> [plugins are enabled; 
> running with  plugins]
>  http://testurl.com/ => http://origin.com//  <> [plugins are enabled; 
> running with 2 plugins]
>   Reverse Mapping Table with 0 entries
>   Permanent Redirect Mapping Table with 0 entries
>   Temporary Redirect Mapping Table with 0 entries
>   Forward Mapping With Recv Port Table with 0 entries
>   Referer filter default redirect URL: "http://www.example.com/;
> traffic_server: Aborted (Signal sent by tkill() 129399 99)
> traffic_server - STACK TRACE:
> /opt/trafficserver/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4ab5ee]
> /lib64/libpthread.so.0(+0xf100)[0x2ad67f3eb100]
> /lib64/libc.so.6(gsignal+0x37)[0x2ad6803bb5f7]
> /lib64/libc.so.6(abort+0x148)[0x2ad6803bcce8]
> /opt/trafficserver/lib/libtsutil.so.6(+0x28668)[0x2ad67d927668]
> /opt/trafficserver/lib/libtsutil.so.6(+0x286fc)[0x2ad67d9276fc]
> /opt/trafficserver/lib/libtsutil.so.6(+0x269e5)[0x2ad67d9259e5]
> /opt/trafficserver/bin/traffic_server[0x4c7973]
> /opt/trafficserver/libexec/trafficserver/tslua.so(+0x9aeb)[0x2ad695821aeb]
> /opt/trafficserver/bin/traffic_server[0x5834e6]
> 
> It appears, the following code 

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4916?focusedWorklogId=30540=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30540
 ]

ASF GitHub Bot logged work on TS-4916:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 22:00
Start Date: 12/Oct/16 22:00
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/986/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30540)
Time Spent: 2h  (was: 1h 50m)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> next=0x2aaac05d8900
> prev=(nil)
> --- count=1 ---
> id=27
> this=0x2aaac05d8900

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4916?focusedWorklogId=30539=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30539
 ]

ASF GitHub Bot logged work on TS-4916:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 22:00
Start Date: 12/Oct/16 22:00
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/878/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30539)
Time Spent: 2h  (was: 1h 50m)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 2h
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> next=0x2aaac05d8900
> prev=(nil)
> --- count=1 ---
> id=27
> this=0x2aaac05d8900
> 

[GitHub] trafficserver issue #1100: TS-4916: Fix for an H2-infinite-loop deadlock

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/878/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1100: TS-4916: Fix for an H2-infinite-loop deadlock

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/986/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

Jenkins build is back to normal : osx-master » clang,osx,debug #1230

[jenkins]

See 

[jira] [Work logged] (TS-4959) Remove an old remnant of MSIE UA detection

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4959?focusedWorklogId=30538=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30538
 ]

ASF GitHub Bot logged work on TS-4959:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 21:57
Start Date: 12/Oct/16 21:57
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1101
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/877/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30538)
Time Spent: 40m  (was: 0.5h)

> Remove an old remnant of MSIE UA detection
> --
>
> Key: TS-4959
> URL: https://issues.apache.org/jira/browse/TS-4959
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 40m
>  Remaining Estimate: 0h
>
> This might have been part of an old option as well, that seems to have been 
> removed (so this code was likely left around by mistake).



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

[GitHub] trafficserver issue #1101: TS-4959: Remove remnants of old UA configurations...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1101
  
Linux build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/877/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Updated] (TS-4938) Crash due to null client_vc

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4938:
---
Backport to Version: 6.2.1  (was: 6.2.1, 7.0.0)

> Crash due to null client_vc
> ---
>
> Key: TS-4938
> URL: https://issues.apache.org/jira/browse/TS-4938
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Saw this crash while testing fix for TS-4813.  Have a fix that checks 
> get_netvc() returns a non-NULL.  Should make a more comprehensive review on 
> the use of get_netvc() in HttpTransact.cc/HttpSM.cc
> {code}
> #0  0x0053ed2c in NetVConnection::get_local_addr (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:60
> #1  0x0057dca4 in NetVConnection::get_local_port (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:82
> #2  0x00627844 in 
> HttpTransact::initialize_state_variables_from_request (s=0x2b65700d4a98, 
> obsolete_incoming_request=0x2b65700d51b8)
> at HttpTransact.cc:5709
> #3  0x00632bd1 in HttpTransact::build_error_response 
> (s=0x2b65700d4a98, status_code=HTTP_STATUS_BAD_GATEWAY, 
> reason_phrase_or_null=0x7fb86c "Server Hangup", error_body_type=0x7fb87a 
> "connect#hangup", format=0x0) at HttpTransact.cc:8141
> #4  0x006311fa in HttpTransact::handle_server_died (s=0x2b65700d4a98) 
> at HttpTransact.cc:7789
> #5  0x00620bbc in HttpTransact::handle_server_connection_not_open 
> (s=0x2b65700d4a98) at HttpTransact.cc:3991
> #6  0x0061fd43 in HttpTransact::handle_response_from_server 
> (s=0x2b65700d4a98) at HttpTransact.cc:3824
> #7  0x0061d762 in HttpTransact::HandleResponse (s=0x2b65700d4a98) at 
> HttpTransact.cc:3401
> #8  0x005fc928 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b65700d4a20, 
> f=0x61cf9a ) at 
> HttpSM.cc:7116
> #9  0x005f6902 in HttpSM::handle_server_setup_error 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:5505
> #10 0x005e88a4 in HttpSM::state_send_server_request_header 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:2053
> #11 0x005eb3ba in HttpSM::main_handler (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at HttpSM.cc:2655
> #12 0x005145ac in Continuation::handleEvent (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at ../iocore/eventsystem/I_Continuation.h:153
> #13 0x0079906f in write_signal_and_update (event=104, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:174
> #14 0x007992a6 in write_signal_done (event=104, nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:216
> #15 0x0079a475 in write_to_net_io (nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140, thread=0x2b64f71b1010) at UnixNetVConnection.cc:547
> #16 0x00799dc7 in write_to_net (nh=0x2b64f71b4cf0, vc=0x2aabd0037140, 
> thread=0x2b64f71b1010) at UnixNetVConnection.cc:414
> #17 0x0079129d in NetHandler::mainNetEvent (this=0x2b64f71b4cf0, 
> event=5, e=0x1646ac0) at UnixNet.cc:515
> #18 0x005145ac in Continuation::handleEvent (this=0x2b64f71b4cf0, 
> event=5, data=0x1646ac0) at ../iocore/eventsystem/I_Continuation.h:153
> #19 0x007bc90a in EThread::process_event (this=0x2b64f71b1010, 
> e=0x1646ac0, calling_code=5) at UnixEThread.cc:143
> #20 0x007bcf0d in EThread::execute (this=0x2b64f71b1010) at 
> UnixEThread.cc:270
> #21 0x007bbf1e in spawn_thread_internal (a=0x15731f0) at Thread.cc:84
> #22 0x2b64f5fcfaa1 in start_thread () from /lib64/libpthread.so.0
> #23 0x0032310e893d in clone () from /lib64/libc.so.6
> {code}



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

[jira] [Updated] (TS-4938) Crash due to null client_vc

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4938:
---
Fix Version/s: (was: 7.1.0)
   7.0.0

> Crash due to null client_vc
> ---
>
> Key: TS-4938
> URL: https://issues.apache.org/jira/browse/TS-4938
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Susan Hinrichs
>Assignee: Susan Hinrichs
> Fix For: 7.0.0
>
>  Time Spent: 2h 50m
>  Remaining Estimate: 0h
>
> Saw this crash while testing fix for TS-4813.  Have a fix that checks 
> get_netvc() returns a non-NULL.  Should make a more comprehensive review on 
> the use of get_netvc() in HttpTransact.cc/HttpSM.cc
> {code}
> #0  0x0053ed2c in NetVConnection::get_local_addr (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:60
> #1  0x0057dca4 in NetVConnection::get_local_port (this=0x0) at 
> ../iocore/net/P_NetVConnection.h:82
> #2  0x00627844 in 
> HttpTransact::initialize_state_variables_from_request (s=0x2b65700d4a98, 
> obsolete_incoming_request=0x2b65700d51b8)
> at HttpTransact.cc:5709
> #3  0x00632bd1 in HttpTransact::build_error_response 
> (s=0x2b65700d4a98, status_code=HTTP_STATUS_BAD_GATEWAY, 
> reason_phrase_or_null=0x7fb86c "Server Hangup", error_body_type=0x7fb87a 
> "connect#hangup", format=0x0) at HttpTransact.cc:8141
> #4  0x006311fa in HttpTransact::handle_server_died (s=0x2b65700d4a98) 
> at HttpTransact.cc:7789
> #5  0x00620bbc in HttpTransact::handle_server_connection_not_open 
> (s=0x2b65700d4a98) at HttpTransact.cc:3991
> #6  0x0061fd43 in HttpTransact::handle_response_from_server 
> (s=0x2b65700d4a98) at HttpTransact.cc:3824
> #7  0x0061d762 in HttpTransact::HandleResponse (s=0x2b65700d4a98) at 
> HttpTransact.cc:3401
> #8  0x005fc928 in HttpSM::call_transact_and_set_next_state 
> (this=0x2b65700d4a20, 
> f=0x61cf9a ) at 
> HttpSM.cc:7116
> #9  0x005f6902 in HttpSM::handle_server_setup_error 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:5505
> #10 0x005e88a4 in HttpSM::state_send_server_request_header 
> (this=0x2b65700d4a20, event=104, data=0x2aabd00372d8) at HttpSM.cc:2053
> #11 0x005eb3ba in HttpSM::main_handler (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at HttpSM.cc:2655
> #12 0x005145ac in Continuation::handleEvent (this=0x2b65700d4a20, 
> event=104, data=0x2aabd00372d8) at ../iocore/eventsystem/I_Continuation.h:153
> #13 0x0079906f in write_signal_and_update (event=104, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:174
> #14 0x007992a6 in write_signal_done (event=104, nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140) at UnixNetVConnection.cc:216
> #15 0x0079a475 in write_to_net_io (nh=0x2b64f71b4cf0, 
> vc=0x2aabd0037140, thread=0x2b64f71b1010) at UnixNetVConnection.cc:547
> #16 0x00799dc7 in write_to_net (nh=0x2b64f71b4cf0, vc=0x2aabd0037140, 
> thread=0x2b64f71b1010) at UnixNetVConnection.cc:414
> #17 0x0079129d in NetHandler::mainNetEvent (this=0x2b64f71b4cf0, 
> event=5, e=0x1646ac0) at UnixNet.cc:515
> #18 0x005145ac in Continuation::handleEvent (this=0x2b64f71b4cf0, 
> event=5, data=0x1646ac0) at ../iocore/eventsystem/I_Continuation.h:153
> #19 0x007bc90a in EThread::process_event (this=0x2b64f71b1010, 
> e=0x1646ac0, calling_code=5) at UnixEThread.cc:143
> #20 0x007bcf0d in EThread::execute (this=0x2b64f71b1010) at 
> UnixEThread.cc:270
> #21 0x007bbf1e in spawn_thread_internal (a=0x15731f0) at Thread.cc:84
> #22 0x2b64f5fcfaa1 in start_thread () from /lib64/libpthread.so.0
> #23 0x0032310e893d in clone () from /lib64/libc.so.6
> {code}



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

[jira] [Work logged] (TS-4959) Remove an old remnant of MSIE UA detection

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4959?focusedWorklogId=30537=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30537
 ]

ASF GitHub Bot logged work on TS-4959:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 21:50
Start Date: 12/Oct/16 21:50
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1101
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/985/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30537)
Time Spent: 0.5h  (was: 20m)

> Remove an old remnant of MSIE UA detection
> --
>
> Key: TS-4959
> URL: https://issues.apache.org/jira/browse/TS-4959
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 0.5h
>  Remaining Estimate: 0h
>
> This might have been part of an old option as well, that seems to have been 
> removed (so this code was likely left around by mistake).



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

[GitHub] trafficserver issue #1101: TS-4959: Remove remnants of old UA configurations...

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1101
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/985/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4916?focusedWorklogId=30536=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30536
 ]

ASF GitHub Bot logged work on TS-4916:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 21:48
Start Date: 12/Oct/16 21:48
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
Try again [approve ci].


Issue Time Tracking
---

Worklog Id: (was: 30536)
Time Spent: 1h 50m  (was: 1h 40m)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> next=0x2aaac05d8900
> prev=(nil)
> --- count=1 ---
> id=27
> this=0x2aaac05d8900
> next=0x2ae5b6bbec00
> prev=0x2ae673f0c840
> --- count=2 ---
> id=19
> 

[GitHub] trafficserver issue #1100: TS-4916: Fix for an H2-infinite-loop deadlock

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
Try again [approve ci].


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1101: TS-4959: Remove remnants of old UA configurations...

[bryancall]

Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/1101
  
👍  - Looks good


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4959) Remove an old remnant of MSIE UA detection

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4959?focusedWorklogId=30535=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30535
 ]

ASF GitHub Bot logged work on TS-4959:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 21:44
Start Date: 12/Oct/16 21:44
Worklog Time Spent: 10m 
  Work Description: Github user bryancall commented on the issue:

https://github.com/apache/trafficserver/pull/1101
  
  - Looks good


Issue Time Tracking
---

Worklog Id: (was: 30535)
Time Spent: 20m  (was: 10m)

> Remove an old remnant of MSIE UA detection
> --
>
> Key: TS-4959
> URL: https://issues.apache.org/jira/browse/TS-4959
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 20m
>  Remaining Estimate: 0h
>
> This might have been part of an old option as well, that seems to have been 
> removed (so this code was likely left around by mistake).



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

[GitHub] trafficserver pull request #1101: TS-4959: Remove remnants of old UA configu...

[zwoop]

GitHub user zwoop opened a pull request:

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

TS-4959: Remove remnants of old UA configurations and handling

I made this as two commits:

1) Remove some definitely strange code around MSIE.

2) Remove all the code around the accept_encoding_filter_enabled.


For #2, this configuration doesn't actually exist in RecordsConfig.cc, and 
it's also missing all possible ways of configuring the regular expressions that 
it needs. So I figured, we can just nuke it :).

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

$ git pull https://github.com/zwoop/trafficserver TS-4959

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

https://github.com/apache/trafficserver/pull/1101.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 #1101


commit 2e2fad5dc67999f0831f8481b61e04408844228c
Author: Leif Hedstrom 
Date:   2016-10-12T19:51:08Z

TS-4959: Remove remnants of an old browser

commit 25b7900a4574edf9b11bcb02307e02a310e80c41
Author: Leif Hedstrom 
Date:   2016-10-12T21:18:24Z

TS-4959: Remove remnants of an configuration / UA




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Work logged] (TS-4959) Remove an old remnant of MSIE UA detection

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4959?focusedWorklogId=30534=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30534
 ]

ASF GitHub Bot logged work on TS-4959:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 21:33
Start Date: 12/Oct/16 21:33
Worklog Time Spent: 10m 
  Work Description: GitHub user zwoop opened a pull request:

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

TS-4959: Remove remnants of old UA configurations and handling

I made this as two commits:

1) Remove some definitely strange code around MSIE.

2) Remove all the code around the accept_encoding_filter_enabled.


For #2, this configuration doesn't actually exist in RecordsConfig.cc, and 
it's also missing all possible ways of configuring the regular expressions that 
it needs. So I figured, we can just nuke it :).

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

$ git pull https://github.com/zwoop/trafficserver TS-4959

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

https://github.com/apache/trafficserver/pull/1101.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 #1101


commit 2e2fad5dc67999f0831f8481b61e04408844228c
Author: Leif Hedstrom 
Date:   2016-10-12T19:51:08Z

TS-4959: Remove remnants of an old browser

commit 25b7900a4574edf9b11bcb02307e02a310e80c41
Author: Leif Hedstrom 
Date:   2016-10-12T21:18:24Z

TS-4959: Remove remnants of an configuration / UA




Issue Time Tracking
---

Worklog Id: (was: 30534)
Time Spent: 10m
Remaining Estimate: 0h

> Remove an old remnant of MSIE UA detection
> --
>
> Key: TS-4959
> URL: https://issues.apache.org/jira/browse/TS-4959
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Leif Hedstrom
>Assignee: Leif Hedstrom
> Fix For: 7.1.0
>
>  Time Spent: 10m
>  Remaining Estimate: 0h
>
> This might have been part of an old option as well, that seems to have been 
> removed (so this code was likely left around by mistake).



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

[GitHub] trafficserver issue #1100: TS-4916: Fix for an H2-infinite-loop deadlock

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/984/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[GitHub] trafficserver issue #1100: TS-4916: Fix for an H2-infinite-loop deadlock

[zwoop]

Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
Just a heads up, but this PR is against 6.2.x branch, the code has 
diverged, so will need one PR for 6.2.x and one for master. @gtenev Please make 
a PR for master at your earliest convenience as well, but sounds like they will 
be so different that we need two reviews.


---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Issue Comment Deleted] (TS-4963) Option to allow keepalive for PluginVC.

[James Peach (JIRA)]

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

James Peach updated TS-4963:

Comment: was deleted

(was: cc [~shinrich] [~jacksontj])

> Option to allow keepalive for PluginVC.
> ---
>
> Key: TS-4963
> URL: https://issues.apache.org/jira/browse/TS-4963
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core, Plugins
>Reporter: James Peach
>
> Since it will take some time to explore and test a fix for TS-4960, add a 
> configuration knob to allow keepalive on internal connections.



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

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4916?focusedWorklogId=30532=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30532
 ]

ASF GitHub Bot logged work on TS-4916:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 21:16
Start Date: 12/Oct/16 21:16
Worklog Time Spent: 10m 
  Work Description: Github user zwoop commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
Just a heads up, but this PR is against 6.2.x branch, the code has 
diverged, so will need one PR for 6.2.x and one for master. @gtenev Please make 
a PR for master at your earliest convenience as well, but sounds like they will 
be so different that we need two reviews.


Issue Time Tracking
---

Worklog Id: (was: 30532)
Time Spent: 1h 40m  (was: 1.5h)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) 

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4916?focusedWorklogId=30531=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30531
 ]

ASF GitHub Bot logged work on TS-4916:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 21:10
Start Date: 12/Oct/16 21:10
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
FreeBSD build *successful*! See 
https://ci.trafficserver.apache.org/job/Github-FreeBSD/984/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30531)
Time Spent: 1.5h  (was: 1h 20m)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 1.5h
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> next=0x2aaac05d8900
> prev=(nil)
> --- count=1 ---
> id=27
> 

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4916?focusedWorklogId=30530=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30530
 ]

ASF GitHub Bot logged work on TS-4916:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 21:08
Start Date: 12/Oct/16 21:08
Worklog Time Spent: 10m 
  Work Description: Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/876/ for details.
 



Issue Time Tracking
---

Worklog Id: (was: 30530)
Time Spent: 1h 20m  (was: 1h 10m)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 1h 20m
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> #19 EThread::execute (this=0x2aaab2406000) at UnixEThread.cc:275
> #20 0x2ae8c0e6 in spawn_thread_internal (a=0x2aaab0b25bb0) at 
> Thread.cc:86
> #21 0x2d6b3aa1 in start_thread (arg=0x2aaab3d04700) at 
> pthread_create.c:301
> #22 0x2e8bc93d in clone () at 
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:115
> {code}
> Here is the stream_list trace.
> {code}
> (gdb) thread 51
> [Switching to thread 51 (Thread 0x2aaab3d04700 (LWP 34270))]
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> (gdb) trace_list stream_list
> --- count=0 ---
> id=29
> this=0x2ae673f0c840
> next=0x2aaac05d8900
> prev=(nil)
> --- count=1 ---
> id=27
> this=0x2aaac05d8900

[GitHub] trafficserver issue #1100: TS-4916: Fix for an H2-infinite-loop deadlock

[atsci]

Github user atsci commented on the issue:

https://github.com/apache/trafficserver/pull/1100
  
Linux build *failed*! See 
https://ci.trafficserver.apache.org/job/Github-Linux/876/ for details.
 



---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---

[jira] [Commented] (TS-4963) Option to allow keepalive for PluginVC.

[James Peach (JIRA)]

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

James Peach commented on TS-4963:
-

cc [~shinrich] [~jacksontj]

> Option to allow keepalive for PluginVC.
> ---
>
> Key: TS-4963
> URL: https://issues.apache.org/jira/browse/TS-4963
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core, Plugins
>Reporter: James Peach
>
> Since it will take some time to explore and test a fix for TS-4960, add a 
> configuration knob to allow keepalive on internal connections.



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

[jira] [Commented] (TS-4963) Option to allow keepalive for PluginVC.

[James Peach (JIRA)]

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

James Peach commented on TS-4963:
-

cc [~shinrich] [~jacksontj]

> Option to allow keepalive for PluginVC.
> ---
>
> Key: TS-4963
> URL: https://issues.apache.org/jira/browse/TS-4963
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Configuration, Core, Plugins
>Reporter: James Peach
>
> Since it will take some time to explore and test a fix for TS-4960, add a 
> configuration knob to allow keepalive on internal connections.



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

[jira] [Created] (TS-4963) Option to allow keepalive for PluginVC.

[James Peach (JIRA)]

James Peach created TS-4963:
---

 Summary: Option to allow keepalive for PluginVC.
 Key: TS-4963
 URL: https://issues.apache.org/jira/browse/TS-4963
 Project: Traffic Server
  Issue Type: Improvement
  Components: Configuration, Core, Plugins
Reporter: James Peach


Since it will take some time to explore and test a fix for TS-4960, add a 
configuration knob to allow keepalive on internal connections.



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

[jira] [Work logged] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock

[ASF GitHub Bot (JIRA)]

 [ 
https://issues.apache.org/jira/browse/TS-4916?focusedWorklogId=30529=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30529
 ]

ASF GitHub Bot logged work on TS-4916:
--

Author: ASF GitHub Bot
Created on: 12/Oct/16 20:59
Start Date: 12/Oct/16 20:59
Worklog Time Spent: 10m 
  Work Description: GitHub user gtenev opened a pull request:

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

TS-4916: Fix for an H2-infinite-loop deadlock

This is a fix to prevent destroying of the DLL<> structure and the 
following iteration over Http2ConnectionState::stream_list to fall into an 
infinite loop while holding a lock, which leads to cache updates to start 
failing.

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

$ git pull https://github.com/gtenev/trafficserver TS-4916

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

https://github.com/apache/trafficserver/pull/1100.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 #1100


commit e84978a18f0d856adfea744a5ab11668e1fc
Author: Gancho Tenev 
Date:   2016-10-11T23:05:14Z

TS-4916 Fix for a H2-infinite-loop deadlock.




Issue Time Tracking
---

Worklog Id: (was: 30529)
Time Spent: 1h 10m  (was: 1h)

> Http2ConnectionState::restart_streams infinite loop causes deadlock 
> 
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>  Time Spent: 1h 10m
>  Remaining Estimate: 0h
>
> Http2ConnectionState::restart_streams falls into an infinite loop while 
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next” 
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0  0x2acf3fee in Http2ConnectionState::restart_streams 
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1  rcv_window_update_frame (cstate=..., frame=...) at 
> Http2ConnectionState.cc:627
> #2  0x2acf9738 in Http2ConnectionState::main_event_handler 
> (this=0x2ae6ba5284c8, event=, edata=) at 
> Http2ConnectionState.cc:823
> #3  0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0, 
> event=2253, this=0x2ae6ba5284c8) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #4  send_connection_event (cont=cont@entry=0x2ae6ba5284c8, 
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at 
> Http2ClientSession.cc:58
> #5  0x2acef462 in Http2ClientSession::state_complete_frame_read 
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at 
> Http2ClientSession.cc:426
> #6  0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #7  Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8  0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #9  Http2ClientSession::state_complete_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:431
> #10 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=0x2ae6ba528290) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #11 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290, 
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #12 0x2ae67e2b in Continuation::handleEvent (data=0x2aab7b237f18, 
> event=100, this=) at 
> ../../iocore/eventsystem/I_Continuation.h:153
> #13 read_signal_and_update (vc=0x2aab7b237e00, vc@entry=0x1, 
> event=event@entry=100) at UnixNetVConnection.cc:153
> #14 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aab7b237e00, 
> event=event@entry=100) at UnixNetVConnection.cc:1036
> #15 0x2ae47653 in SSLNetVConnection::net_read_io 
> (this=0x2aab7b237e00, nh=0x2aaab2409cc0, lthread=0x2aaab2406000) at 
> SSLNetVConnection.cc:595
> #16 0x2ae5558c in NetHandler::mainNetEvent (this=0x2aaab2409cc0, 
> event=, e=) at UnixNet.cc:513
> #17 0x2ae8d2e6 in Continuation::handleEvent (data=0x2aaab0bfa700, 
> event=5, this=) at I_Continuation.h:153
> #18 EThread::process_event (calling_code=5, e=0x2aaab0bfa700, 
> this=0x2aaab2406000) at UnixEThread.cc:148
> 

[GitHub] trafficserver pull request #1100: TS-4916: Fix for an H2-infinite-loop deadl...

[gtenev]

GitHub user gtenev opened a pull request:

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

TS-4916: Fix for an H2-infinite-loop deadlock

This is a fix to prevent destroying of the DLL<> structure and the 
following iteration over Http2ConnectionState::stream_list to fall into an 
infinite loop while holding a lock, which leads to cache updates to start 
failing.

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

$ git pull https://github.com/gtenev/trafficserver TS-4916

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

https://github.com/apache/trafficserver/pull/1100.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 #1100


commit e84978a18f0d856adfea744a5ab11668e1fc
Author: Gancho Tenev 
Date:   2016-10-11T23:05:14Z

TS-4916 Fix for a H2-infinite-loop deadlock.




---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---