[jira] [Commented] (TS-4197) Add memory debugging

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4197:


Github user bryancall commented on the pull request:

https://github.com/apache/trafficserver/pull/470#issuecomment-183182412
  
Looks good


> Add memory debugging
> 
>
> Key: TS-4197
> URL: https://issues.apache.org/jira/browse/TS-4197
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Phil Sorber
>Assignee: Phil Sorber
> Fix For: 6.2.0
>
>
> We need more debug for things like hugepage allocation and freelists



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

[jira] [Resolved] (TS-4197) Add memory debugging

[Phil Sorber (JIRA)]

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

Phil Sorber resolved TS-4197.
-
Resolution: Fixed

> Add memory debugging
> 
>
> Key: TS-4197
> URL: https://issues.apache.org/jira/browse/TS-4197
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Phil Sorber
>Assignee: Phil Sorber
> Fix For: 6.2.0
>
>
> We need more debug for things like hugepage allocation and freelists



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

[jira] [Commented] (TS-4197) Add memory debugging

[ASF subversion and git services (JIRA)]

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

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

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

TS-4197: Add memory debugging

This closes #470


> Add memory debugging
> 
>
> Key: TS-4197
> URL: https://issues.apache.org/jira/browse/TS-4197
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Phil Sorber
>Assignee: Phil Sorber
> Fix For: 6.2.0
>
>
> We need more debug for things like hugepage allocation and freelists



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

[jira] [Commented] (TS-4197) Add memory debugging

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4197:


Github user asfgit closed the pull request at:

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


> Add memory debugging
> 
>
> Key: TS-4197
> URL: https://issues.apache.org/jira/browse/TS-4197
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Phil Sorber
>Assignee: Phil Sorber
> Fix For: 6.2.0
>
>
> We need more debug for things like hugepage allocation and freelists



--
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/3721811/

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

[jira] [Updated] (TS-4198) Excessive memory allocations from HostDB with huge tables enabled

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4198:
--
Fix Version/s: 6.2.0

> Excessive memory allocations from HostDB with huge tables enabled
> -
>
> Key: TS-4198
> URL: https://issues.apache.org/jira/browse/TS-4198
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Leif Hedstrom
> Fix For: 6.2.0
>
>
> [~psudaemon] and I have been debugging some memory issues for a while now, 
> and with the new debug tags Phil added, we believe we've tracked it down to a 
> missing release of cachedir buffers. This became significant amount of RAM 
> with HostDB allocations (which by default is 32MB, but can be much bigger).
> The suggestion is to restore the previous cleanup, with huge pages logic 
> added.



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

[jira] [Created] (TS-4198) Excessive memory allocations from HostDB with huge tables enabled

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4198:
-

 Summary: Excessive memory allocations from HostDB with huge tables 
enabled
 Key: TS-4198
 URL: https://issues.apache.org/jira/browse/TS-4198
 Project: Traffic Server
  Issue Type: Bug
  Components: Cache
Reporter: Leif Hedstrom


[~psudaemon] and I have been debugging some memory issues for a while now, and 
with the new debug tags Phil added, we believe we've tracked it down to a 
missing release of cachedir buffers. This became significant amount of RAM with 
HostDB allocations (which by default is 32MB, but can be much bigger).

The suggestion is to restore the previous cleanup, with huge pages logic added.



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

[jira] [Updated] (TS-4198) Excessive memory allocations from HostDB with huge tables enabled

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4198:
--
Backport to Version: 6.1.2  (was: 6.2.1)

> Excessive memory allocations from HostDB with huge tables enabled
> -
>
> Key: TS-4198
> URL: https://issues.apache.org/jira/browse/TS-4198
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Leif Hedstrom
> Fix For: 6.2.0
>
>
> [~psudaemon] and I have been debugging some memory issues for a while now, 
> and with the new debug tags Phil added, we believe we've tracked it down to a 
> missing release of cachedir buffers. This became significant amount of RAM 
> with HostDB allocations (which by default is 32MB, but can be much bigger).
> The suggestion is to restore the previous cleanup, with huge pages logic 
> added.



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

[jira] [Updated] (TS-4198) Excessive memory allocations from HostDB with huge tables enabled

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4198:
--
Assignee: Phil Sorber

> Excessive memory allocations from HostDB with huge tables enabled
> -
>
> Key: TS-4198
> URL: https://issues.apache.org/jira/browse/TS-4198
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Cache
>Reporter: Leif Hedstrom
>Assignee: Phil Sorber
> Fix For: 6.2.0
>
>
> [~psudaemon] and I have been debugging some memory issues for a while now, 
> and with the new debug tags Phil added, we believe we've tracked it down to a 
> missing release of cachedir buffers. This became significant amount of RAM 
> with HostDB allocations (which by default is 32MB, but can be much bigger).
> The suggestion is to restore the previous cleanup, with huge pages logic 
> added.



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

[jira] [Commented] (TS-3917) Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3917:


GitHub user bryancall opened a pull request:

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

TS-3917: Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame



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

$ git pull https://github.com/bryancall/trafficserver TS-3917

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

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


commit 7cf04c6053cf1880af7b83dfb43be0eb2b70aeb1
Author: Bryan Call 
Date:   2016-02-12T05:13:16Z

TS-3917: Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame




> Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame
> ---
>
> Key: TS-3917
> URL: https://issues.apache.org/jira/browse/TS-3917
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
>Priority: Critical
> Fix For: 6.2.0
>
>
> After fix for TS-3492, ATS sends only {{SETTINGS_INITIAL_WINDOW_SIZE}} in 
> first SETTINGS Frame.
> ATS should send SETTINGS Parameters when values in records.config is 
> different from default value of RFC7540 (6.5.2 Defined SETTINGS Parameters).
> For example, {{SETTINGS_MAX_CONCURRENT_STREAMS}} is unlimited in RFC7540, but 
> default value in records.config is 100. ATS should send this value in first 
> SETTINGS Frame but not.



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

[jira] [Commented] (TS-3917) Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3917:


Github user masaori335 commented on the pull request:

https://github.com/apache/trafficserver/pull/471#issuecomment-183182665
  
+1


> Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame
> ---
>
> Key: TS-3917
> URL: https://issues.apache.org/jira/browse/TS-3917
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
>Priority: Critical
> Fix For: 6.2.0
>
>
> After fix for TS-3492, ATS sends only {{SETTINGS_INITIAL_WINDOW_SIZE}} in 
> first SETTINGS Frame.
> ATS should send SETTINGS Parameters when values in records.config is 
> different from default value of RFC7540 (6.5.2 Defined SETTINGS Parameters).
> For example, {{SETTINGS_MAX_CONCURRENT_STREAMS}} is unlimited in RFC7540, but 
> default value in records.config is 100. ATS should send this value in first 
> SETTINGS Frame but not.



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

[jira] [Commented] (TS-3917) Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame

[ASF subversion and git services (JIRA)]

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

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

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

TS-3917: Sending only SETTINGS_INITIAL_WINDOW_SIZE in

This closes #471


> Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame
> ---
>
> Key: TS-3917
> URL: https://issues.apache.org/jira/browse/TS-3917
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
>Priority: Critical
> Fix For: 6.2.0
>
>
> After fix for TS-3492, ATS sends only {{SETTINGS_INITIAL_WINDOW_SIZE}} in 
> first SETTINGS Frame.
> ATS should send SETTINGS Parameters when values in records.config is 
> different from default value of RFC7540 (6.5.2 Defined SETTINGS Parameters).
> For example, {{SETTINGS_MAX_CONCURRENT_STREAMS}} is unlimited in RFC7540, but 
> default value in records.config is 100. ATS should send this value in first 
> SETTINGS Frame but not.



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

[jira] [Commented] (TS-3917) Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3917:


Github user asfgit closed the pull request at:

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


> Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame
> ---
>
> Key: TS-3917
> URL: https://issues.apache.org/jira/browse/TS-3917
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
>Priority: Critical
> Fix For: 6.2.0
>
>
> After fix for TS-3492, ATS sends only {{SETTINGS_INITIAL_WINDOW_SIZE}} in 
> first SETTINGS Frame.
> ATS should send SETTINGS Parameters when values in records.config is 
> different from default value of RFC7540 (6.5.2 Defined SETTINGS Parameters).
> For example, {{SETTINGS_MAX_CONCURRENT_STREAMS}} is unlimited in RFC7540, but 
> default value in records.config is 100. ATS should send this value in first 
> SETTINGS Frame but not.



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

[jira] [Updated] (TS-4191) Typo of debug tags setting name in Developer Guide

[Eric Sproul (JIRA)]

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

Eric Sproul updated TS-4191:

Priority: Trivial  (was: Major)

> Typo of debug tags setting name in Developer Guide
> --
>
> Key: TS-4191
> URL: https://issues.apache.org/jira/browse/TS-4191
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: Docs
>Reporter: Eric Sproul
>Priority: Trivial
>
> On the page about Debug Tags, the configuration setting is listed as 
> {{proxy.config.diag.debug.tags}} where it should be "diags" (plural).



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

[jira] [Created] (TS-4191) Typo of debug tags setting name in Developer Guide

[Eric Sproul (JIRA)]

Eric Sproul created TS-4191:
---

 Summary: Typo of debug tags setting name in Developer Guide
 Key: TS-4191
 URL: https://issues.apache.org/jira/browse/TS-4191
 Project: Traffic Server
  Issue Type: Bug
  Components: Documentation
Reporter: Eric Sproul


On the page about Debug Tags, the configuration setting is listed as 
{{proxy.config.diag.debug.tags}} where it should be "diags" (plural).



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

[jira] [Updated] (TS-4191) Typo of debug tags setting name in Developer Guide

[Eric Sproul (JIRA)]

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

Eric Sproul updated TS-4191:

Affects Version/s: Docs

> Typo of debug tags setting name in Developer Guide
> --
>
> Key: TS-4191
> URL: https://issues.apache.org/jira/browse/TS-4191
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: Docs
>Reporter: Eric Sproul
>Priority: Trivial
>
> On the page about Debug Tags, the configuration setting is listed as 
> {{proxy.config.diag.debug.tags}} where it should be "diags" (plural).



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

[jira] [Commented] (TS-4191) Typo of debug tags setting name in Developer Guide

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4191:


GitHub user esproul opened a pull request:

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

TS-4191 Typo of debug tags setting name in Developer Guide

Trivial fix.

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

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

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

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


commit 346f0137e99e9f587f4f564c8930120d7b41c174
Author: Eric Sproul 
Date:   2016-02-11T16:17:40Z

TS-4191 Typo of debug tags setting name in Developer Guide




> Typo of debug tags setting name in Developer Guide
> --
>
> Key: TS-4191
> URL: https://issues.apache.org/jira/browse/TS-4191
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: Docs
>Reporter: Eric Sproul
>Priority: Trivial
>
> On the page about Debug Tags, the configuration setting is listed as 
> {{proxy.config.diag.debug.tags}} where it should be "diags" (plural).



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

[jira] [Assigned] (TS-4180) support for serving multiple intermediate cert chains

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs reassigned TS-4180:
--

Assignee: Susan Hinrichs

> support for serving multiple intermediate cert chains
> -
>
> Key: TS-4180
> URL: https://issues.apache.org/jira/browse/TS-4180
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Scott Beardsley
>Assignee: Susan Hinrichs
>  Labels: yahoo
> Fix For: 6.2.0
>
>
> We would like to serve two different intermediate certificate chains for RSA 
> certs and ECDSA certs. Today they are required to be in the same chain. It 
> seems the best way would be to modify "ssl_ca_name" (or 
> proxy.config.ssl.CA.cert.path) to support a comma-delimited list of 
> intermediate files.
> Bonus points if ATS validates that the intermediate chain matches the cert 
> being served (and spits out an error if there is a mismatch)!



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

[jira] [Commented] (TS-4132) Open source Yahoo's ats-inliner plug-in

[ASF subversion and git services (JIRA)]

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

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

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

TS-4132: Removed -std=c++11 from the build


> Open source Yahoo's ats-inliner plug-in
> ---
>
> Key: TS-4132
> URL: https://issues.apache.org/jira/browse/TS-4132
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Daniel Vitor Morilha
> Fix For: 6.2.0
>
>




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

[jira] [Updated] (TS-3866) Browser always prompts for authentication (NTLM) - Regression?

[Aaron McClimont (JIRA)]

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

Aaron McClimont updated TS-3866:

Attachment: HttpSM_4.2.3.diff
HttpSM_4.2.0.diff

> Browser always prompts for authentication (NTLM) - Regression?
> --
>
> Key: TS-3866
> URL: https://issues.apache.org/jira/browse/TS-3866
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 5.3.0, 5.3.1
> Environment: RHEL 6.5 64-bit
>Reporter: Aaron McClimont
>Priority: Critical
>  Labels: Regression
> Fix For: 6.2.0
>
> Attachments: HttpSM_4.2.0.diff, HttpSM_4.2.3.diff
>
>
> NTLM authentication through Apache TrafficServer version 5.3.1 appears to be 
> broken, with the authentication prompt being displayed repeatedly.
> Version 4.1.2 (using the same configuration files) works successfully.
> Notes:
> * HTTPS does not resolve the issue in version 5.3.1 like it does with version 
> 4.1.2
> * proxy.config.http.share_server_sessions is set to 0 (default: 2)
> * proxy.config.http.auth_server_session_private is set to 1
> This issue appears to be related to TS-1491 identified in the 3.2 releases.



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

[jira] [Comment Edited] (TS-3866) Browser always prompts for authentication (NTLM) - Regression?

[Aaron McClimont (JIRA)]

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

Aaron McClimont edited comment on TS-3866 at 2/11/16 11:09 PM:
---

Reverting the following logic in version 4.2.3 back to what existed for 4.1.2 
resolves the issue... but with unknown repercussions:

{code:title=trafficserver-4.2.3/proxy/http/HttpSM_4.2.3.diff}
2944,2950c2944,2952
< // If the option to attach the server session to the client session is set
< // and if the client is still around and the client is keep-alive, attach 
the
< // server session to so the next ka request can use it.  Server sessions 
will
< // be placed into the shared pool if the next incoming request is for a 
different
< // origin server
< if (t_state.http_config_param->attach_server_session_to_client == 1 &&
< ua_session && t_state.client_info.keep_alive == HTTP_KEEPALIVE) {
---
> // If the client is still around, attach the server session
> // to so the next ka request can use it.  We bind privately to the
> // client to add some degree of affinity to the system.  However,
> // we turn off private binding when outbound connections are being
> // limit since it makes it too expensive to initiate a purge of idle
> // server keep-alive sessions
> if (ua_session && t_state.client_info.keep_alive == HTTP_KEEPALIVE &&
> t_state.http_config_param->server_max_connections <= 0 &&
> t_state.txn_conf->origin_max_connections <= 0) {
{code}

Note: Same patch as for 4.2.0, lines are only offset by -3.

patch applied as follows:

{code}
cd trafficserver-4.2.3/proxy/http
patch HttpSM.cc < HttpSM_4.2.3.diff
{code}


was (Author: a_mcclimont):
Reverting the following logic in version 4.2.3 back to what existed for 4.1.2 
resolves the issue... but with unknown repercussions:

{code:title=trafficserver-4.2.3/proxy/http/HttpSM_4.2.3.diff}
2944,2950c2944,2952
< // If the option to attach the server session to the client session is set
< // and if the client is still around and the client is keep-alive, attach 
the
< // server session to so the next ka request can use it.  Server sessions 
will
< // be placed into the shared pool if the next incoming request is for a 
different
< // origin server
< if (t_state.http_config_param->attach_server_session_to_client == 1 &&
< ua_session && t_state.client_info.keep_alive == HTTP_KEEPALIVE) {
---
> // If the client is still around, attach the server session
> // to so the next ka request can use it.  We bind privately to the
> // client to add some degree of affinity to the system.  However,
> // we turn off private binding when outbound connections are being
> // limit since it makes it too expensive to initiate a purge of idle
> // server keep-alive sessions
> if (ua_session && t_state.client_info.keep_alive == HTTP_KEEPALIVE &&
> t_state.http_config_param->server_max_connections <= 0 &&
> t_state.txn_conf->origin_max_connections <= 0) {
{code}

Note: Same patch, lines are only offset by -3.

patch applied as follows:

{code}
cd trafficserver-4.2.3/proxy/http
patch HttpSM.cc < HttpSM_4.2.3.diff
{code}

> Browser always prompts for authentication (NTLM) - Regression?
> --
>
> Key: TS-3866
> URL: https://issues.apache.org/jira/browse/TS-3866
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 5.3.0, 5.3.1
> Environment: RHEL 6.5 64-bit
>Reporter: Aaron McClimont
>Priority: Critical
>  Labels: Regression
> Fix For: 6.2.0
>
> Attachments: HttpSM_4.2.0.diff, HttpSM_4.2.3.diff
>
>
> NTLM authentication through Apache TrafficServer version 5.3.1 appears to be 
> broken, with the authentication prompt being displayed repeatedly.
> Version 4.1.2 (using the same configuration files) works successfully.
> Notes:
> * HTTPS does not resolve the issue in version 5.3.1 like it does with version 
> 4.1.2
> * proxy.config.http.share_server_sessions is set to 0 (default: 2)
> * proxy.config.http.auth_server_session_private is set to 1
> This issue appears to be related to TS-1491 identified in the 3.2 releases.



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

[jira] [Commented] (TS-3866) Browser always prompts for authentication (NTLM) - Regression?

[Aaron McClimont (JIRA)]

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

Aaron McClimont commented on TS-3866:
-

Reverting the following logic in version 5.0.1 back to what existed for 4.1.2 
resolves the issue... but with unknown repercussions:

{code:title=trafficserver-5.0.1/proxy/http/HttpSM_5.0.1.diff}
2908,2914c2908,2916
< // If the option to attach the server session to the client session is set
< // and if the client is still around and the client is keep-alive, attach 
the
< // server session to so the next ka request can use it.  Server sessions 
will
< // be placed into the shared pool if the next incoming request is for a 
different
< // origin server
< if (t_state.http_config_param->attach_server_session_to_client == 1 &&
< ua_session && t_state.client_info.keep_alive == HTTP_KEEPALIVE) {
---
> // If the client is still around, attach the server session
> // to so the next ka request can use it.  We bind privately to the
> // client to add some degree of affinity to the system.  However,
> // we turn off private binding when outbound connections are being
> // limit since it makes it too expensive to initiate a purge of idle
> // server keep-alive sessions
> if (ua_session && t_state.client_info.keep_alive == HTTP_KEEPALIVE &&
> t_state.http_config_param->server_max_connections <= 0 &&
> t_state.txn_conf->origin_max_connections <= 0) {
{code}

Note: Same patch as for 4.2.3, lines are only offset by -36 lines.

patch applied as follows:

{code}
cd trafficserver-5.0.1/proxy/http
patch HttpSM.cc < HttpSM_5.0.1.diff
{code}

> Browser always prompts for authentication (NTLM) - Regression?
> --
>
> Key: TS-3866
> URL: https://issues.apache.org/jira/browse/TS-3866
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 5.3.0, 5.3.1
> Environment: RHEL 6.5 64-bit
>Reporter: Aaron McClimont
>Priority: Critical
>  Labels: Regression
> Fix For: 6.2.0
>
> Attachments: HttpSM_4.2.0.diff, HttpSM_4.2.3.diff, HttpSM_5.0.1.diff
>
>
> NTLM authentication through Apache TrafficServer version 5.3.1 appears to be 
> broken, with the authentication prompt being displayed repeatedly.
> Version 4.1.2 (using the same configuration files) works successfully.
> Notes:
> * HTTPS does not resolve the issue in version 5.3.1 like it does with version 
> 4.1.2
> * proxy.config.http.share_server_sessions is set to 0 (default: 2)
> * proxy.config.http.auth_server_session_private is set to 1
> This issue appears to be related to TS-1491 identified in the 3.2 releases.



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

[jira] [Commented] (TS-3866) Browser always prompts for authentication (NTLM) - Regression?

[Aaron McClimont (JIRA)]

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

Aaron McClimont commented on TS-3866:
-

Reverting the following logic in version 4.2.3 back to what existed for 4.1.2 
resolves the issue... but with unknown repercussions:

{code:title=trafficserver-4.2.3/proxy/http/HttpSM_4.2.3.diff}
2944,2950c2944,2952
< // If the option to attach the server session to the client session is set
< // and if the client is still around and the client is keep-alive, attach 
the
< // server session to so the next ka request can use it.  Server sessions 
will
< // be placed into the shared pool if the next incoming request is for a 
different
< // origin server
< if (t_state.http_config_param->attach_server_session_to_client == 1 &&
< ua_session && t_state.client_info.keep_alive == HTTP_KEEPALIVE) {
---
> // If the client is still around, attach the server session
> // to so the next ka request can use it.  We bind privately to the
> // client to add some degree of affinity to the system.  However,
> // we turn off private binding when outbound connections are being
> // limit since it makes it too expensive to initiate a purge of idle
> // server keep-alive sessions
> if (ua_session && t_state.client_info.keep_alive == HTTP_KEEPALIVE &&
> t_state.http_config_param->server_max_connections <= 0 &&
> t_state.txn_conf->origin_max_connections <= 0) {
{code}

Note: Same patch, lines are only offset by -3.

patch applied as follows:

{code}
cd trafficserver-4.2.3/proxy/http
patch HttpSM.cc < HttpSM_4.2.3.diff
{code}

> Browser always prompts for authentication (NTLM) - Regression?
> --
>
> Key: TS-3866
> URL: https://issues.apache.org/jira/browse/TS-3866
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 5.3.0, 5.3.1
> Environment: RHEL 6.5 64-bit
>Reporter: Aaron McClimont
>Priority: Critical
>  Labels: Regression
> Fix For: 6.2.0
>
>
> NTLM authentication through Apache TrafficServer version 5.3.1 appears to be 
> broken, with the authentication prompt being displayed repeatedly.
> Version 4.1.2 (using the same configuration files) works successfully.
> Notes:
> * HTTPS does not resolve the issue in version 5.3.1 like it does with version 
> 4.1.2
> * proxy.config.http.share_server_sessions is set to 0 (default: 2)
> * proxy.config.http.auth_server_session_private is set to 1
> This issue appears to be related to TS-1491 identified in the 3.2 releases.



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

[jira] [Comment Edited] (TS-3866) Browser always prompts for authentication (NTLM) - Regression?

[Aaron McClimont (JIRA)]

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

Aaron McClimont edited comment on TS-3866 at 2/11/16 11:09 PM:
---

Reverting the following logic in version 4.2.0 back to what existed for 4.1.2 
resolves the issue... but with unknown repercussions:

{code:title=trafficserver-4.2.0/proxy/http/HttpSM_4.2.0.diff}
2947,2953c2947,2955
< // If the option to attach the server session to the client session is set
< // and if the client is still around and the client is keep-alive, attach 
the
< // server session to so the next ka request can use it.  Server sessions 
will
< // be placed into the shared pool if the next incoming request is for a 
different
< // origin server
< if (t_state.http_config_param->attach_server_session_to_client == 1 &&
< ua_session && t_state.client_info.keep_alive == HTTP_KEEPALIVE) {
---
> // If the client is still around, attach the server session
> // to so the next ka request can use it.  We bind privately to the
> // client to add some degree of affinity to the system.  However,
> // we turn off private binding when outbound connections are being
> // limit since it makes it too expensive to initiate a purge of idle
> // server keep-alive sessions
> if (ua_session && t_state.client_info.keep_alive == HTTP_KEEPALIVE &&
> t_state.http_config_param->server_max_connections <= 0 &&
> t_state.txn_conf->origin_max_connections <= 0) {
{code}

patch applied as follows:

{code}
cd trafficserver-4.2.0/proxy/http
patch HttpSM.cc < HttpSM_4.2.0.diff
{code}


was (Author: a_mcclimont):
Reverting the following logic in version 4.2.0 back to what existed for 4.1.2 
resolves the issue... but with unknown repercussions:

{code:title=trafficserver-4.2.0/proxy/http/HttpSM.diff}
2947,2953c2947,2955
< // If the option to attach the server session to the client session is set
< // and if the client is still around and the client is keep-alive, attach 
the
< // server session to so the next ka request can use it.  Server sessions 
will
< // be placed into the shared pool if the next incoming request is for a 
different
< // origin server
< if (t_state.http_config_param->attach_server_session_to_client == 1 &&
< ua_session && t_state.client_info.keep_alive == HTTP_KEEPALIVE) {
---
> // If the client is still around, attach the server session
> // to so the next ka request can use it.  We bind privately to the
> // client to add some degree of affinity to the system.  However,
> // we turn off private binding when outbound connections are being
> // limit since it makes it too expensive to initiate a purge of idle
> // server keep-alive sessions
> if (ua_session && t_state.client_info.keep_alive == HTTP_KEEPALIVE &&
> t_state.http_config_param->server_max_connections <= 0 &&
> t_state.txn_conf->origin_max_connections <= 0) {
{code}

patch applied as follows:

{code}
cd trafficserver-4.2.0/proxy/http
patch HttpSM.cc < HttpSM.diff
{code}

> Browser always prompts for authentication (NTLM) - Regression?
> --
>
> Key: TS-3866
> URL: https://issues.apache.org/jira/browse/TS-3866
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 5.3.0, 5.3.1
> Environment: RHEL 6.5 64-bit
>Reporter: Aaron McClimont
>Priority: Critical
>  Labels: Regression
> Fix For: 6.2.0
>
> Attachments: HttpSM_4.2.0.diff, HttpSM_4.2.3.diff
>
>
> NTLM authentication through Apache TrafficServer version 5.3.1 appears to be 
> broken, with the authentication prompt being displayed repeatedly.
> Version 4.1.2 (using the same configuration files) works successfully.
> Notes:
> * HTTPS does not resolve the issue in version 5.3.1 like it does with version 
> 4.1.2
> * proxy.config.http.share_server_sessions is set to 0 (default: 2)
> * proxy.config.http.auth_server_session_private is set to 1
> This issue appears to be related to TS-1491 identified in the 3.2 releases.



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

[jira] [Updated] (TS-3866) Browser always prompts for authentication (NTLM) - Regression?

[Aaron McClimont (JIRA)]

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

Aaron McClimont updated TS-3866:

Attachment: HttpSM_5.0.1.diff

> Browser always prompts for authentication (NTLM) - Regression?
> --
>
> Key: TS-3866
> URL: https://issues.apache.org/jira/browse/TS-3866
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 5.3.0, 5.3.1
> Environment: RHEL 6.5 64-bit
>Reporter: Aaron McClimont
>Priority: Critical
>  Labels: Regression
> Fix For: 6.2.0
>
> Attachments: HttpSM_4.2.0.diff, HttpSM_4.2.3.diff, HttpSM_5.0.1.diff
>
>
> NTLM authentication through Apache TrafficServer version 5.3.1 appears to be 
> broken, with the authentication prompt being displayed repeatedly.
> Version 4.1.2 (using the same configuration files) works successfully.
> Notes:
> * HTTPS does not resolve the issue in version 5.3.1 like it does with version 
> 4.1.2
> * proxy.config.http.share_server_sessions is set to 0 (default: 2)
> * proxy.config.http.auth_server_session_private is set to 1
> This issue appears to be related to TS-1491 identified in the 3.2 releases.



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

[jira] [Assigned] (TS-4179) OCSP stapling broken with RSA+ECDSA cert serving

[Susan Hinrichs (JIRA)]

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

Susan Hinrichs reassigned TS-4179:
--

Assignee: Susan Hinrichs

> OCSP stapling broken with RSA+ECDSA cert serving
> 
>
> Key: TS-4179
> URL: https://issues.apache.org/jira/browse/TS-4179
> Project: Traffic Server
>  Issue Type: Bug
>  Components: SSL
>Reporter: Scott Beardsley
>Assignee: Susan Hinrichs
>  Labels: yahoo
> Fix For: 6.2.0
>
>
> When I try to serve both an RSA and an ECDSA cert using a config like so:
> $ grep ocsp records.config
> CONFIG proxy.config.ssl.ocsp.enabled INT 1
> $ grep -v ^# ssl_multicert.config
> dest_ip=* ssl_cert_name=ecdsa.crt,rsa.crt ssl_key_name=ecdsa.key,rsa.key
> I get the following error displayed in diags.log:
> WARNING: fail to configure SSL_CTX for OCSP Stapling info for certificate at 
> ecdsa.crt
> Also when I connect via either of the following I get no stapled cert:
> $ openssl s_client -connect localhost:443 -cipher 'ECDHE-ECDSA-AES128-SHA' 
> -status
> CONNECTED(0003)
> OCSP response: no response sent
> ...
> $ openssl s_client -connect localhost:443 -cipher 'ECDHE-RSA-AES128-SHA' 
> -status
> CONNECTED(0003)
> OCSP response: no response sent
> ...
> $
> Here are the debug log messages:
> diags.log:[Feb  5 22:44:03.230] Server {0x2afd2845bd80} WARNING: fail to 
> configure SSL_CTX for OCSP Stapling info for certificate at ecdsa.crt
> traffic.out:[Feb  5 22:44:03.230] Server {0x2afd2845bd80} DEBUG: (ssl) ssl 
> ocsp stapling is enabled
> traffic.out:[Feb  5 22:44:41.250] Server {0x2afd2ab89700} DEBUG: (ssl) 
> ssl_callback_ocsp_stapling: fail to get certificate information



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

[jira] [Updated] (TS-4179) OCSP stapling broken with RSA+ECDSA cert serving

[Scott Beardsley (JIRA)]

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

Scott Beardsley updated TS-4179:

Issue Type: Improvement  (was: Bug)

> OCSP stapling broken with RSA+ECDSA cert serving
> 
>
> Key: TS-4179
> URL: https://issues.apache.org/jira/browse/TS-4179
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Scott Beardsley
>Assignee: Susan Hinrichs
>  Labels: yahoo
> Fix For: 6.2.0
>
>
> When I try to serve both an RSA and an ECDSA cert using a config like so:
> $ grep ocsp records.config
> CONFIG proxy.config.ssl.ocsp.enabled INT 1
> $ grep -v ^# ssl_multicert.config
> dest_ip=* ssl_cert_name=ecdsa.crt,rsa.crt ssl_key_name=ecdsa.key,rsa.key
> I get the following error displayed in diags.log:
> WARNING: fail to configure SSL_CTX for OCSP Stapling info for certificate at 
> ecdsa.crt
> Also when I connect via either of the following I get no stapled cert:
> $ openssl s_client -connect localhost:443 -cipher 'ECDHE-ECDSA-AES128-SHA' 
> -status
> CONNECTED(0003)
> OCSP response: no response sent
> ...
> $ openssl s_client -connect localhost:443 -cipher 'ECDHE-RSA-AES128-SHA' 
> -status
> CONNECTED(0003)
> OCSP response: no response sent
> ...
> $
> Here are the debug log messages:
> diags.log:[Feb  5 22:44:03.230] Server {0x2afd2845bd80} WARNING: fail to 
> configure SSL_CTX for OCSP Stapling info for certificate at ecdsa.crt
> traffic.out:[Feb  5 22:44:03.230] Server {0x2afd2845bd80} DEBUG: (ssl) ssl 
> ocsp stapling is enabled
> traffic.out:[Feb  5 22:44:41.250] Server {0x2afd2ab89700} DEBUG: (ssl) 
> ssl_callback_ocsp_stapling: fail to get certificate information



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

[jira] [Updated] (TS-4179) OCSP stapling broken with RSA+ECDSA cert serving

[Scott Beardsley (JIRA)]

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

Scott Beardsley updated TS-4179:

Priority: Minor  (was: Major)

> OCSP stapling broken with RSA+ECDSA cert serving
> 
>
> Key: TS-4179
> URL: https://issues.apache.org/jira/browse/TS-4179
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: SSL
>Reporter: Scott Beardsley
>Assignee: Susan Hinrichs
>Priority: Minor
>  Labels: yahoo
> Fix For: 6.2.0
>
>
> When I try to serve both an RSA and an ECDSA cert using a config like so:
> $ grep ocsp records.config
> CONFIG proxy.config.ssl.ocsp.enabled INT 1
> $ grep -v ^# ssl_multicert.config
> dest_ip=* ssl_cert_name=ecdsa.crt,rsa.crt ssl_key_name=ecdsa.key,rsa.key
> I get the following error displayed in diags.log:
> WARNING: fail to configure SSL_CTX for OCSP Stapling info for certificate at 
> ecdsa.crt
> Also when I connect via either of the following I get no stapled cert:
> $ openssl s_client -connect localhost:443 -cipher 'ECDHE-ECDSA-AES128-SHA' 
> -status
> CONNECTED(0003)
> OCSP response: no response sent
> ...
> $ openssl s_client -connect localhost:443 -cipher 'ECDHE-RSA-AES128-SHA' 
> -status
> CONNECTED(0003)
> OCSP response: no response sent
> ...
> $
> Here are the debug log messages:
> diags.log:[Feb  5 22:44:03.230] Server {0x2afd2845bd80} WARNING: fail to 
> configure SSL_CTX for OCSP Stapling info for certificate at ecdsa.crt
> traffic.out:[Feb  5 22:44:03.230] Server {0x2afd2845bd80} DEBUG: (ssl) ssl 
> ocsp stapling is enabled
> traffic.out:[Feb  5 22:44:41.250] Server {0x2afd2ab89700} DEBUG: (ssl) 
> ssl_callback_ocsp_stapling: fail to get certificate information



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

[jira] [Commented] (TS-4132) Open source Yahoo's ats-inliner plug-in

[ASF subversion and git services (JIRA)]

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

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

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

TS-4132: Remove auto


> Open source Yahoo's ats-inliner plug-in
> ---
>
> Key: TS-4132
> URL: https://issues.apache.org/jira/browse/TS-4132
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Daniel Vitor Morilha
> Fix For: 6.2.0
>
>




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

[jira] [Commented] (TS-4181) Memory leak in aio threads when shutting down

[ASF subversion and git services (JIRA)]

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

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

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

TS-4181: Memory leak in aio threads when shutting down

This closes #463


> Memory leak in aio threads when shutting down
> -
>
> Key: TS-4181
> URL: https://issues.apache.org/jira/browse/TS-4181
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.1.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>
> {code}
> Direct leak of 504 byte(s) in 7 object(s) allocated from:
> #0 0x7fcf4c5e7872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0xbe4c44 in aio_init_fildes 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:252
> #2 0xbe5ccf in aio_queue_req 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:358
> #3 0xbe5f02 in ink_aio_read(AIOCallback*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:426
> #4 0xb1d1fa in CacheDisk::open(char*, long, long, int, int, bool) 
> /home/bcall/dev/apache/trafficserver/iocore/cache/CacheDisk.cc:76
> #5 0xaddc69 in CacheProcessor::start_internal(int) 
> /home/bcall/dev/apache/trafficserver/iocore/cache/Cache.cc:720
> #6 0x49511f in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1808
> #7 0x7fcf4952457f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> Direct leak of 72 byte(s) in 1 object(s) allocated from:
> #0 0x7fcf4c5e7872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0xbe4ebc in aio_init_fildes 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:250
> #2 0xbe5ccf in aio_queue_req 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:358
> #3 0xbe5f02 in ink_aio_read(AIOCallback*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:426
> #4 0xb1d1fa in CacheDisk::open(char*, long, long, int, int, bool) 
> /home/bcall/dev/apache/trafficserver/iocore/cache/CacheDisk.cc:76
> #5 0xaddc69 in CacheProcessor::start_internal(int) 
> /home/bcall/dev/apache/trafficserver/iocore/cache/Cache.cc:720
> #6 0x49511f in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1808
> #7 0x7fcf4952457f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> {code}



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

[jira] [Commented] (TS-4181) Memory leak in aio threads when shutting down

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4181:


Github user asfgit closed the pull request at:

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


> Memory leak in aio threads when shutting down
> -
>
> Key: TS-4181
> URL: https://issues.apache.org/jira/browse/TS-4181
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.1.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>
> {code}
> Direct leak of 504 byte(s) in 7 object(s) allocated from:
> #0 0x7fcf4c5e7872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0xbe4c44 in aio_init_fildes 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:252
> #2 0xbe5ccf in aio_queue_req 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:358
> #3 0xbe5f02 in ink_aio_read(AIOCallback*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:426
> #4 0xb1d1fa in CacheDisk::open(char*, long, long, int, int, bool) 
> /home/bcall/dev/apache/trafficserver/iocore/cache/CacheDisk.cc:76
> #5 0xaddc69 in CacheProcessor::start_internal(int) 
> /home/bcall/dev/apache/trafficserver/iocore/cache/Cache.cc:720
> #6 0x49511f in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1808
> #7 0x7fcf4952457f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> Direct leak of 72 byte(s) in 1 object(s) allocated from:
> #0 0x7fcf4c5e7872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0xbe4ebc in aio_init_fildes 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:250
> #2 0xbe5ccf in aio_queue_req 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:358
> #3 0xbe5f02 in ink_aio_read(AIOCallback*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:426
> #4 0xb1d1fa in CacheDisk::open(char*, long, long, int, int, bool) 
> /home/bcall/dev/apache/trafficserver/iocore/cache/CacheDisk.cc:76
> #5 0xaddc69 in CacheProcessor::start_internal(int) 
> /home/bcall/dev/apache/trafficserver/iocore/cache/Cache.cc:720
> #6 0x49511f in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1808
> #7 0x7fcf4952457f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> {code}



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

[jira] [Resolved] (TS-4181) Memory leak in aio threads when shutting down

[Bryan Call (JIRA)]

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

Bryan Call resolved TS-4181.

Resolution: Fixed

> Memory leak in aio threads when shutting down
> -
>
> Key: TS-4181
> URL: https://issues.apache.org/jira/browse/TS-4181
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.1.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>
> {code}
> Direct leak of 504 byte(s) in 7 object(s) allocated from:
> #0 0x7fcf4c5e7872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0xbe4c44 in aio_init_fildes 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:252
> #2 0xbe5ccf in aio_queue_req 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:358
> #3 0xbe5f02 in ink_aio_read(AIOCallback*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:426
> #4 0xb1d1fa in CacheDisk::open(char*, long, long, int, int, bool) 
> /home/bcall/dev/apache/trafficserver/iocore/cache/CacheDisk.cc:76
> #5 0xaddc69 in CacheProcessor::start_internal(int) 
> /home/bcall/dev/apache/trafficserver/iocore/cache/Cache.cc:720
> #6 0x49511f in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1808
> #7 0x7fcf4952457f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> Direct leak of 72 byte(s) in 1 object(s) allocated from:
> #0 0x7fcf4c5e7872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0xbe4ebc in aio_init_fildes 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:250
> #2 0xbe5ccf in aio_queue_req 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:358
> #3 0xbe5f02 in ink_aio_read(AIOCallback*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:426
> #4 0xb1d1fa in CacheDisk::open(char*, long, long, int, int, bool) 
> /home/bcall/dev/apache/trafficserver/iocore/cache/CacheDisk.cc:76
> #5 0xaddc69 in CacheProcessor::start_internal(int) 
> /home/bcall/dev/apache/trafficserver/iocore/cache/Cache.cc:720
> #6 0x49511f in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1808
> #7 0x7fcf4952457f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> {code}



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

[jira] [Resolved] (TS-4178) Memory leak in SplitDNSConfig when shutting down

[Bryan Call (JIRA)]

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

Bryan Call resolved TS-4178.

Resolution: Fixed

> Memory leak in SplitDNSConfig when shutting down
> 
>
> Key: TS-4178
> URL: https://issues.apache.org/jira/browse/TS-4178
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Affects Versions: 6.1.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>
> {code}
> =
> ==7628==ERROR: LeakSanitizer: detected memory leaks
> Direct leak of 8 byte(s) in 1 object(s) allocated from:
> #0 0x7f27d1b01872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0xa1a1c3 in SplitDNSConfig::startup() 
> /home/bcall/dev/apache/trafficserver/iocore/dns/SplitDNS.cc:133
> #2 0x494e59 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1767
> #3 0x7f27cea3e57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> Indirect leak of 80 byte(s) in 1 object(s) allocated from:
> #0 0x7f4dee606e72 in memalign (/lib64/libasan.so.2+0x98e72)
> #1 0x7f4dee337d91 in ats_memalign 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:112
> #2 0x7f4dee338cb2 in ink_freelist_new 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_queue.cc:181
> #3 0xa1a1e0 in ClassAllocator::alloc() 
> ../../lib/ts/Allocator.h:122
> #4 0xa1a1e0 in new_ProxyMutex() ../../iocore/eventsystem/I_Lock.h:555
> #5 0xa1a1e0 in SplitDNSConfig::startup() ../../mgmt/ProxyConfig.h:121
> #6 0x494e59 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1767
> #7 0x7f4deb54457f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> {code}



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

[jira] [Commented] (TS-3917) Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3917:


Github user zwoop commented on the pull request:

https://github.com/apache/trafficserver/pull/466#issuecomment-183162557
  
+1


> Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame
> ---
>
> Key: TS-3917
> URL: https://issues.apache.org/jira/browse/TS-3917
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
>Priority: Critical
> Fix For: 6.2.0
>
>
> After fix for TS-3492, ATS sends only {{SETTINGS_INITIAL_WINDOW_SIZE}} in 
> first SETTINGS Frame.
> ATS should send SETTINGS Parameters when values in records.config is 
> different from default value of RFC7540 (6.5.2 Defined SETTINGS Parameters).
> For example, {{SETTINGS_MAX_CONCURRENT_STREAMS}} is unlimited in RFC7540, but 
> default value in records.config is 100. ATS should send this value in first 
> SETTINGS Frame but not.



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

[jira] [Commented] (TS-4132) Open source Yahoo's ats-inliner plug-in

[ASF subversion and git services (JIRA)]

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

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

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

TS-4132: Replace nullptr with NULL


> Open source Yahoo's ats-inliner plug-in
> ---
>
> Key: TS-4132
> URL: https://issues.apache.org/jira/browse/TS-4132
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Daniel Vitor Morilha
> Fix For: 6.2.0
>
>




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

[jira] [Commented] (TS-4132) Open source Yahoo's ats-inliner plug-in

[ASF subversion and git services (JIRA)]

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

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

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

TS-4132: clang-format


> Open source Yahoo's ats-inliner plug-in
> ---
>
> Key: TS-4132
> URL: https://issues.apache.org/jira/browse/TS-4132
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Daniel Vitor Morilha
> Fix For: 6.2.0
>
>




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

[jira] [Commented] (TS-4178) Memory leak in SplitDNSConfig when shutting down

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4178:


Github user asfgit closed the pull request at:

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


> Memory leak in SplitDNSConfig when shutting down
> 
>
> Key: TS-4178
> URL: https://issues.apache.org/jira/browse/TS-4178
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Affects Versions: 6.1.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>
> {code}
> =
> ==7628==ERROR: LeakSanitizer: detected memory leaks
> Direct leak of 8 byte(s) in 1 object(s) allocated from:
> #0 0x7f27d1b01872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0xa1a1c3 in SplitDNSConfig::startup() 
> /home/bcall/dev/apache/trafficserver/iocore/dns/SplitDNS.cc:133
> #2 0x494e59 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1767
> #3 0x7f27cea3e57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> Indirect leak of 80 byte(s) in 1 object(s) allocated from:
> #0 0x7f4dee606e72 in memalign (/lib64/libasan.so.2+0x98e72)
> #1 0x7f4dee337d91 in ats_memalign 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:112
> #2 0x7f4dee338cb2 in ink_freelist_new 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_queue.cc:181
> #3 0xa1a1e0 in ClassAllocator::alloc() 
> ../../lib/ts/Allocator.h:122
> #4 0xa1a1e0 in new_ProxyMutex() ../../iocore/eventsystem/I_Lock.h:555
> #5 0xa1a1e0 in SplitDNSConfig::startup() ../../mgmt/ProxyConfig.h:121
> #6 0x494e59 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1767
> #7 0x7f4deb54457f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> {code}



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

[jira] [Commented] (TS-4178) Memory leak in SplitDNSConfig when shutting down

[ASF subversion and git services (JIRA)]

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

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

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

TS-4178: Memory leak in SplitDNSConfig when shutting down

This closes #464


> Memory leak in SplitDNSConfig when shutting down
> 
>
> Key: TS-4178
> URL: https://issues.apache.org/jira/browse/TS-4178
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Affects Versions: 6.1.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>
> {code}
> =
> ==7628==ERROR: LeakSanitizer: detected memory leaks
> Direct leak of 8 byte(s) in 1 object(s) allocated from:
> #0 0x7f27d1b01872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0xa1a1c3 in SplitDNSConfig::startup() 
> /home/bcall/dev/apache/trafficserver/iocore/dns/SplitDNS.cc:133
> #2 0x494e59 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1767
> #3 0x7f27cea3e57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> Indirect leak of 80 byte(s) in 1 object(s) allocated from:
> #0 0x7f4dee606e72 in memalign (/lib64/libasan.so.2+0x98e72)
> #1 0x7f4dee337d91 in ats_memalign 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:112
> #2 0x7f4dee338cb2 in ink_freelist_new 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_queue.cc:181
> #3 0xa1a1e0 in ClassAllocator::alloc() 
> ../../lib/ts/Allocator.h:122
> #4 0xa1a1e0 in new_ProxyMutex() ../../iocore/eventsystem/I_Lock.h:555
> #5 0xa1a1e0 in SplitDNSConfig::startup() ../../mgmt/ProxyConfig.h:121
> #6 0x494e59 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1767
> #7 0x7f4deb54457f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> {code}



--
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/3721649/

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

[jira] [Commented] (TS-3917) Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3917:


GitHub user bryancall opened a pull request:

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

TS-3917: Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame



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

$ git pull https://github.com/bryancall/trafficserver TS-3917

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

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


commit 7f7e16884c80b8e8ddfb4f8d56f4ac1bb9635512
Author: Bryan Call 
Date:   2016-02-12T02:58:08Z

TS-3917: Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame




> Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame
> ---
>
> Key: TS-3917
> URL: https://issues.apache.org/jira/browse/TS-3917
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
>Priority: Critical
> Fix For: 6.2.0
>
>
> After fix for TS-3492, ATS sends only {{SETTINGS_INITIAL_WINDOW_SIZE}} in 
> first SETTINGS Frame.
> ATS should send SETTINGS Parameters when values in records.config is 
> different from default value of RFC7540 (6.5.2 Defined SETTINGS Parameters).
> For example, {{SETTINGS_MAX_CONCURRENT_STREAMS}} is unlimited in RFC7540, but 
> default value in records.config is 100. ATS should send this value in first 
> SETTINGS Frame but not.



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

[jira] [Updated] (TS-4196) Memory leak from main_thread on shutdown

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4196:
---
Affects Version/s: 6.1.1

> Memory leak from main_thread on shutdown
> 
>
> Key: TS-4196
> URL: https://issues.apache.org/jira/browse/TS-4196
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Bryan Call
>Assignee: Bryan Call
>
> {code}
> =
> ==27000==ERROR: LeakSanitizer: detected memory leaks
> Indirect leak of 1051936 byte(s) in 1 object(s) allocated from:
> #0 0x7ff7472e2872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0x493eb9 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1603
> #2 0x7ff74421f57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> Indirect leak of 80 byte(s) in 1 object(s) allocated from:
> #0 0x7ff7472e1e72 in memalign (/lib64/libasan.so.2+0x98e72)
> #1 0x7ff747012d91 in ats_memalign 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:112
> #2 0x7ff747013cb2 in ink_freelist_new 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_queue.cc:181
> #3 0xd31dab in ClassAllocator::alloc() 
> ../../lib/ts/Allocator.h:122
> #4 0xd31dab in new_ProxyMutex() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Lock.h:555
> #5 0xd31dab in Thread::Thread() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/Thread.cc:46
> #6 0xd37410 in EThread::EThread() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:46
> #7 0x493ec4 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1603
> #8 0x7ff74421f57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> SUMMARY: AddressSanitizer: 1052016 byte(s) leaked in 2 allocation(s).
> {code}



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

[jira] [Assigned] (TS-4196) Memory leak from main_thread on shutdown

[Bryan Call (JIRA)]

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

Bryan Call reassigned TS-4196:
--

Assignee: Bryan Call

> Memory leak from main_thread on shutdown
> 
>
> Key: TS-4196
> URL: https://issues.apache.org/jira/browse/TS-4196
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Bryan Call
>Assignee: Bryan Call
>
> {code}
> =
> ==27000==ERROR: LeakSanitizer: detected memory leaks
> Indirect leak of 1051936 byte(s) in 1 object(s) allocated from:
> #0 0x7ff7472e2872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0x493eb9 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1603
> #2 0x7ff74421f57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> Indirect leak of 80 byte(s) in 1 object(s) allocated from:
> #0 0x7ff7472e1e72 in memalign (/lib64/libasan.so.2+0x98e72)
> #1 0x7ff747012d91 in ats_memalign 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:112
> #2 0x7ff747013cb2 in ink_freelist_new 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_queue.cc:181
> #3 0xd31dab in ClassAllocator::alloc() 
> ../../lib/ts/Allocator.h:122
> #4 0xd31dab in new_ProxyMutex() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Lock.h:555
> #5 0xd31dab in Thread::Thread() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/Thread.cc:46
> #6 0xd37410 in EThread::EThread() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:46
> #7 0x493ec4 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1603
> #8 0x7ff74421f57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> SUMMARY: AddressSanitizer: 1052016 byte(s) leaked in 2 allocation(s).
> {code}



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

[jira] [Commented] (TS-4196) Memory leak from main_thread on shutdown

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4196:


GitHub user bryancall opened a pull request:

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

TS-4196: Memory leak from main_thread on shutdown



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

$ git pull https://github.com/bryancall/trafficserver TS-4196

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

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


commit 3a7a868c690e54e386e5a48281599c3eca12a9ef
Author: Bryan Call 
Date:   2016-02-12T03:51:53Z

TS-4196: Memory leak from main_thread on shutdown




> Memory leak from main_thread on shutdown
> 
>
> Key: TS-4196
> URL: https://issues.apache.org/jira/browse/TS-4196
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>
> {code}
> =
> ==27000==ERROR: LeakSanitizer: detected memory leaks
> Indirect leak of 1051936 byte(s) in 1 object(s) allocated from:
> #0 0x7ff7472e2872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0x493eb9 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1603
> #2 0x7ff74421f57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> Indirect leak of 80 byte(s) in 1 object(s) allocated from:
> #0 0x7ff7472e1e72 in memalign (/lib64/libasan.so.2+0x98e72)
> #1 0x7ff747012d91 in ats_memalign 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:112
> #2 0x7ff747013cb2 in ink_freelist_new 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_queue.cc:181
> #3 0xd31dab in ClassAllocator::alloc() 
> ../../lib/ts/Allocator.h:122
> #4 0xd31dab in new_ProxyMutex() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Lock.h:555
> #5 0xd31dab in Thread::Thread() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/Thread.cc:46
> #6 0xd37410 in EThread::EThread() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:46
> #7 0x493ec4 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1603
> #8 0x7ff74421f57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> SUMMARY: AddressSanitizer: 1052016 byte(s) leaked in 2 allocation(s).
> {code}



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

[jira] [Updated] (TS-4196) Memory leak from main_thread on shutdown

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4196:
---
Fix Version/s: 6.2.0

> Memory leak from main_thread on shutdown
> 
>
> Key: TS-4196
> URL: https://issues.apache.org/jira/browse/TS-4196
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>
> {code}
> =
> ==27000==ERROR: LeakSanitizer: detected memory leaks
> Indirect leak of 1051936 byte(s) in 1 object(s) allocated from:
> #0 0x7ff7472e2872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0x493eb9 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1603
> #2 0x7ff74421f57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> Indirect leak of 80 byte(s) in 1 object(s) allocated from:
> #0 0x7ff7472e1e72 in memalign (/lib64/libasan.so.2+0x98e72)
> #1 0x7ff747012d91 in ats_memalign 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:112
> #2 0x7ff747013cb2 in ink_freelist_new 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_queue.cc:181
> #3 0xd31dab in ClassAllocator::alloc() 
> ../../lib/ts/Allocator.h:122
> #4 0xd31dab in new_ProxyMutex() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Lock.h:555
> #5 0xd31dab in Thread::Thread() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/Thread.cc:46
> #6 0xd37410 in EThread::EThread() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:46
> #7 0x493ec4 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1603
> #8 0x7ff74421f57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> SUMMARY: AddressSanitizer: 1052016 byte(s) leaked in 2 allocation(s).
> {code}



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

[jira] [Commented] (TS-4132) Open source Yahoo's ats-inliner plug-in

[ASF subversion and git services (JIRA)]

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

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

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

TS-4132: Fix for FreeBSD 10 build


> Open source Yahoo's ats-inliner plug-in
> ---
>
> Key: TS-4132
> URL: https://issues.apache.org/jira/browse/TS-4132
> Project: Traffic Server
>  Issue Type: New Feature
>  Components: Plugins
>Reporter: Daniel Vitor Morilha
> Fix For: 6.2.0
>
>




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

[jira] [Commented] (TS-3917) Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3917:


Github user asfgit closed the pull request at:

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


> Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame
> ---
>
> Key: TS-3917
> URL: https://issues.apache.org/jira/browse/TS-3917
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
>Priority: Critical
> Fix For: 6.2.0
>
>
> After fix for TS-3492, ATS sends only {{SETTINGS_INITIAL_WINDOW_SIZE}} in 
> first SETTINGS Frame.
> ATS should send SETTINGS Parameters when values in records.config is 
> different from default value of RFC7540 (6.5.2 Defined SETTINGS Parameters).
> For example, {{SETTINGS_MAX_CONCURRENT_STREAMS}} is unlimited in RFC7540, but 
> default value in records.config is 100. ATS should send this value in first 
> SETTINGS Frame but not.



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

[jira] [Updated] (TS-3917) Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3917:
---
Backport to Version: 6.1.2

> Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame
> ---
>
> Key: TS-3917
> URL: https://issues.apache.org/jira/browse/TS-3917
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
>Priority: Critical
> Fix For: 6.2.0
>
>
> After fix for TS-3492, ATS sends only {{SETTINGS_INITIAL_WINDOW_SIZE}} in 
> first SETTINGS Frame.
> ATS should send SETTINGS Parameters when values in records.config is 
> different from default value of RFC7540 (6.5.2 Defined SETTINGS Parameters).
> For example, {{SETTINGS_MAX_CONCURRENT_STREAMS}} is unlimited in RFC7540, but 
> default value in records.config is 100. ATS should send this value in first 
> SETTINGS Frame but not.



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

[jira] [Commented] (TS-3917) Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame

[ASF subversion and git services (JIRA)]

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

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

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

TS-3917: Sending only SETTINGS_INITIAL_WINDOW_SIZE in

This closes #466


> Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame
> ---
>
> Key: TS-3917
> URL: https://issues.apache.org/jira/browse/TS-3917
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
>Priority: Critical
> Fix For: 6.2.0
>
>
> After fix for TS-3492, ATS sends only {{SETTINGS_INITIAL_WINDOW_SIZE}} in 
> first SETTINGS Frame.
> ATS should send SETTINGS Parameters when values in records.config is 
> different from default value of RFC7540 (6.5.2 Defined SETTINGS Parameters).
> For example, {{SETTINGS_MAX_CONCURRENT_STREAMS}} is unlimited in RFC7540, but 
> default value in records.config is 100. ATS should send this value in first 
> SETTINGS Frame but not.



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

[jira] [Resolved] (TS-3917) Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame

[Bryan Call (JIRA)]

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

Bryan Call resolved TS-3917.

Resolution: Fixed

> Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame
> ---
>
> Key: TS-3917
> URL: https://issues.apache.org/jira/browse/TS-3917
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
>Priority: Critical
> Fix For: 6.2.0
>
>
> After fix for TS-3492, ATS sends only {{SETTINGS_INITIAL_WINDOW_SIZE}} in 
> first SETTINGS Frame.
> ATS should send SETTINGS Parameters when values in records.config is 
> different from default value of RFC7540 (6.5.2 Defined SETTINGS Parameters).
> For example, {{SETTINGS_MAX_CONCURRENT_STREAMS}} is unlimited in RFC7540, but 
> default value in records.config is 100. ATS should send this value in first 
> SETTINGS Frame but not.



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

[jira] [Commented] (TS-4196) Memory leak from main_thread on shutdown

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4196:


Github user zwoop commented on the pull request:

https://github.com/apache/trafficserver/pull/467#issuecomment-183171794
  
+1.


> Memory leak from main_thread on shutdown
> 
>
> Key: TS-4196
> URL: https://issues.apache.org/jira/browse/TS-4196
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>
> {code}
> =
> ==27000==ERROR: LeakSanitizer: detected memory leaks
> Indirect leak of 1051936 byte(s) in 1 object(s) allocated from:
> #0 0x7ff7472e2872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0x493eb9 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1603
> #2 0x7ff74421f57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> Indirect leak of 80 byte(s) in 1 object(s) allocated from:
> #0 0x7ff7472e1e72 in memalign (/lib64/libasan.so.2+0x98e72)
> #1 0x7ff747012d91 in ats_memalign 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:112
> #2 0x7ff747013cb2 in ink_freelist_new 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_queue.cc:181
> #3 0xd31dab in ClassAllocator::alloc() 
> ../../lib/ts/Allocator.h:122
> #4 0xd31dab in new_ProxyMutex() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Lock.h:555
> #5 0xd31dab in Thread::Thread() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/Thread.cc:46
> #6 0xd37410 in EThread::EThread() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:46
> #7 0x493ec4 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1603
> #8 0x7ff74421f57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> SUMMARY: AddressSanitizer: 1052016 byte(s) leaked in 2 allocation(s).
> {code}



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

[jira] [Commented] (TS-4196) Memory leak from main_thread on shutdown

[ASF subversion and git services (JIRA)]

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

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

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

TS-4196: Memory leak from main_thread on shutdown

This closes #467


> Memory leak from main_thread on shutdown
> 
>
> Key: TS-4196
> URL: https://issues.apache.org/jira/browse/TS-4196
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>
> {code}
> =
> ==27000==ERROR: LeakSanitizer: detected memory leaks
> Indirect leak of 1051936 byte(s) in 1 object(s) allocated from:
> #0 0x7ff7472e2872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0x493eb9 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1603
> #2 0x7ff74421f57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> Indirect leak of 80 byte(s) in 1 object(s) allocated from:
> #0 0x7ff7472e1e72 in memalign (/lib64/libasan.so.2+0x98e72)
> #1 0x7ff747012d91 in ats_memalign 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:112
> #2 0x7ff747013cb2 in ink_freelist_new 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_queue.cc:181
> #3 0xd31dab in ClassAllocator::alloc() 
> ../../lib/ts/Allocator.h:122
> #4 0xd31dab in new_ProxyMutex() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Lock.h:555
> #5 0xd31dab in Thread::Thread() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/Thread.cc:46
> #6 0xd37410 in EThread::EThread() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:46
> #7 0x493ec4 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1603
> #8 0x7ff74421f57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> SUMMARY: AddressSanitizer: 1052016 byte(s) leaked in 2 allocation(s).
> {code}



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

[jira] [Commented] (TS-4196) Memory leak from main_thread on shutdown

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4196:


Github user asfgit closed the pull request at:

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


> Memory leak from main_thread on shutdown
> 
>
> Key: TS-4196
> URL: https://issues.apache.org/jira/browse/TS-4196
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>
> {code}
> =
> ==27000==ERROR: LeakSanitizer: detected memory leaks
> Indirect leak of 1051936 byte(s) in 1 object(s) allocated from:
> #0 0x7ff7472e2872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0x493eb9 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1603
> #2 0x7ff74421f57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> Indirect leak of 80 byte(s) in 1 object(s) allocated from:
> #0 0x7ff7472e1e72 in memalign (/lib64/libasan.so.2+0x98e72)
> #1 0x7ff747012d91 in ats_memalign 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:112
> #2 0x7ff747013cb2 in ink_freelist_new 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_queue.cc:181
> #3 0xd31dab in ClassAllocator::alloc() 
> ../../lib/ts/Allocator.h:122
> #4 0xd31dab in new_ProxyMutex() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Lock.h:555
> #5 0xd31dab in Thread::Thread() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/Thread.cc:46
> #6 0xd37410 in EThread::EThread() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:46
> #7 0x493ec4 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1603
> #8 0x7ff74421f57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> SUMMARY: AddressSanitizer: 1052016 byte(s) leaked in 2 allocation(s).
> {code}



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

[jira] [Resolved] (TS-4196) Memory leak from main_thread on shutdown

[Bryan Call (JIRA)]

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

Bryan Call resolved TS-4196.

Resolution: Fixed

> Memory leak from main_thread on shutdown
> 
>
> Key: TS-4196
> URL: https://issues.apache.org/jira/browse/TS-4196
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.1.1
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>
> {code}
> =
> ==27000==ERROR: LeakSanitizer: detected memory leaks
> Indirect leak of 1051936 byte(s) in 1 object(s) allocated from:
> #0 0x7ff7472e2872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0x493eb9 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1603
> #2 0x7ff74421f57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> Indirect leak of 80 byte(s) in 1 object(s) allocated from:
> #0 0x7ff7472e1e72 in memalign (/lib64/libasan.so.2+0x98e72)
> #1 0x7ff747012d91 in ats_memalign 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:112
> #2 0x7ff747013cb2 in ink_freelist_new 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_queue.cc:181
> #3 0xd31dab in ClassAllocator::alloc() 
> ../../lib/ts/Allocator.h:122
> #4 0xd31dab in new_ProxyMutex() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/I_Lock.h:555
> #5 0xd31dab in Thread::Thread() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/Thread.cc:46
> #6 0xd37410 in EThread::EThread() 
> /home/bcall/dev/apache/trafficserver/iocore/eventsystem/UnixEThread.cc:46
> #7 0x493ec4 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1603
> #8 0x7ff74421f57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> SUMMARY: AddressSanitizer: 1052016 byte(s) leaked in 2 allocation(s).
> {code}



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

[jira] [Commented] (TS-3917) Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3917:


Github user bryancall commented on the pull request:

https://github.com/apache/trafficserver/pull/466#issuecomment-183174731
  
@masaori335 I am pretty sure the compare when setting the settings uses 
this value to compare with.


> Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame
> ---
>
> Key: TS-3917
> URL: https://issues.apache.org/jira/browse/TS-3917
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
>Priority: Critical
> Fix For: 6.2.0
>
>
> After fix for TS-3492, ATS sends only {{SETTINGS_INITIAL_WINDOW_SIZE}} in 
> first SETTINGS Frame.
> ATS should send SETTINGS Parameters when values in records.config is 
> different from default value of RFC7540 (6.5.2 Defined SETTINGS Parameters).
> For example, {{SETTINGS_MAX_CONCURRENT_STREAMS}} is unlimited in RFC7540, but 
> default value in records.config is 100. ATS should send this value in first 
> SETTINGS Frame but not.



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

[jira] [Commented] (TS-3917) Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3917:


Github user masaori335 commented on the pull request:

https://github.com/apache/trafficserver/pull/466#issuecomment-183175215
  
@bryancall Oh really? I'll check.


> Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame
> ---
>
> Key: TS-3917
> URL: https://issues.apache.org/jira/browse/TS-3917
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
>Priority: Critical
> Fix For: 6.2.0
>
>
> After fix for TS-3492, ATS sends only {{SETTINGS_INITIAL_WINDOW_SIZE}} in 
> first SETTINGS Frame.
> ATS should send SETTINGS Parameters when values in records.config is 
> different from default value of RFC7540 (6.5.2 Defined SETTINGS Parameters).
> For example, {{SETTINGS_MAX_CONCURRENT_STREAMS}} is unlimited in RFC7540, but 
> default value in records.config is 100. ATS should send this value in first 
> SETTINGS Frame but not.



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

[jira] [Commented] (TS-4066) Memory leaks in gmake check tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4066:


GitHub user bryancall opened a pull request:

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

TS-4066: Memory leaks in gmake check tests

This fixes leaks in test_List

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

$ git pull https://github.com/bryancall/trafficserver TS-4066

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

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


commit 7feabf3cec81451f54a441534d42174499c3c0df
Author: Bryan Call 
Date:   2016-02-12T04:27:46Z

TS-4066: Memory leaks in gmake check tests




> Memory leaks in gmake check tests
> -
>
> Key: TS-4066
> URL: https://issues.apache.org/jira/browse/TS-4066
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 6.0.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>




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

[jira] [Commented] (TS-3917) Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3917:


Github user masaori335 commented on a diff in the pull request:

https://github.com/apache/trafficserver/pull/466#discussion_r52704287
  
--- Diff: proxy/http2/HTTP2.cc ---
@@ -727,7 +727,7 @@ http2_decode_header_blocks(HTTPHdr *hdr, const uint8_t 
*buf_start, const uint8_t
 }
 
 // Initialize this subsystem with librecords configs (for now)
-uint32_t Http2::max_concurrent_streams = 100;
+uint32_t Http2::max_concurrent_streams = 4294967295;
--- End diff --

This variable is override by `proxy.config.http2.max_concurrent_streams_in` 
in 
[Http2::init()](https://github.com/apache/trafficserver/blob/master/proxy/http2/HTTP2.cc#L743).
IMO, where we should change is `HTTP2_MAX_CONCURRENT_STREAMS` in 
[HTTP2.h#L57](https://github.com/apache/trafficserver/blob/master/proxy/http2/HTTP2.h#L57)


> Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame
> ---
>
> Key: TS-3917
> URL: https://issues.apache.org/jira/browse/TS-3917
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
>Priority: Critical
> Fix For: 6.2.0
>
>
> After fix for TS-3492, ATS sends only {{SETTINGS_INITIAL_WINDOW_SIZE}} in 
> first SETTINGS Frame.
> ATS should send SETTINGS Parameters when values in records.config is 
> different from default value of RFC7540 (6.5.2 Defined SETTINGS Parameters).
> For example, {{SETTINGS_MAX_CONCURRENT_STREAMS}} is unlimited in RFC7540, but 
> default value in records.config is 100. ATS should send this value in first 
> SETTINGS Frame but not.



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

[jira] [Created] (TS-4197) Add memory debugging

[Phil Sorber (JIRA)]

Phil Sorber created TS-4197:
---

 Summary: Add memory debugging
 Key: TS-4197
 URL: https://issues.apache.org/jira/browse/TS-4197
 Project: Traffic Server
  Issue Type: Improvement
Reporter: Phil Sorber


We need more debug for things like hugepage allocation and freelists



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

[jira] [Commented] (TS-3917) Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3917:


Github user bryancall commented on the pull request:

https://github.com/apache/trafficserver/pull/466#issuecomment-183178115
  
@masaori335 You are right :)


> Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame
> ---
>
> Key: TS-3917
> URL: https://issues.apache.org/jira/browse/TS-3917
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
>Priority: Critical
> Fix For: 6.2.0
>
>
> After fix for TS-3492, ATS sends only {{SETTINGS_INITIAL_WINDOW_SIZE}} in 
> first SETTINGS Frame.
> ATS should send SETTINGS Parameters when values in records.config is 
> different from default value of RFC7540 (6.5.2 Defined SETTINGS Parameters).
> For example, {{SETTINGS_MAX_CONCURRENT_STREAMS}} is unlimited in RFC7540, but 
> default value in records.config is 100. ATS should send this value in first 
> SETTINGS Frame but not.



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

[jira] [Commented] (TS-3917) Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-3917:


Github user masaori335 commented on the pull request:

https://github.com/apache/trafficserver/pull/466#issuecomment-183178397
  
@bryancall OK :)


> Sending only SETTINGS_INITIAL_WINDOW_SIZE in SETTINGS Frame
> ---
>
> Key: TS-3917
> URL: https://issues.apache.org/jira/browse/TS-3917
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Bryan Call
>Priority: Critical
> Fix For: 6.2.0
>
>
> After fix for TS-3492, ATS sends only {{SETTINGS_INITIAL_WINDOW_SIZE}} in 
> first SETTINGS Frame.
> ATS should send SETTINGS Parameters when values in records.config is 
> different from default value of RFC7540 (6.5.2 Defined SETTINGS Parameters).
> For example, {{SETTINGS_MAX_CONCURRENT_STREAMS}} is unlimited in RFC7540, but 
> default value in records.config is 100. ATS should send this value in first 
> SETTINGS Frame but not.



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

[jira] [Commented] (TS-4172) Cleanup debug logs of Http2ConnectionState

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4172:


Github user masaori335 commented on the pull request:

https://github.com/apache/trafficserver/pull/454#issuecomment-183178568
  
Please take another look


> Cleanup debug logs of Http2ConnectionState
> --
>
> Key: TS-4172
> URL: https://issues.apache.org/jira/browse/TS-4172
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 6.2.0
>
>
> 1. {{http2_cs}} debug tag is used in {{Http2ClientSession}} and 
> {{Http2ConnectionState}} classes. This sometimes makes me confused when I 
> debug HTTP/2 components.
> It is better to change debug tag of {{Http2ConnectionState}} to 
> {{http2_conn}}.
> 2. Some debug logs has stream id. It is better that other debug logs in 
> {{Http2ConnectionState}} has stream id too.



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

[jira] [Commented] (TS-4066) Memory leaks in gmake check tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4066:


Github user masaori335 commented on the pull request:

https://github.com/apache/trafficserver/pull/468#issuecomment-183179482
  
+1


> Memory leaks in gmake check tests
> -
>
> Key: TS-4066
> URL: https://issues.apache.org/jira/browse/TS-4066
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 6.0.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>




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

[jira] [Commented] (TS-4066) Memory leaks in gmake check tests

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4066:


Github user asfgit closed the pull request at:

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


> Memory leaks in gmake check tests
> -
>
> Key: TS-4066
> URL: https://issues.apache.org/jira/browse/TS-4066
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 6.0.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>




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

[jira] [Commented] (TS-4066) Memory leaks in gmake check tests

[ASF subversion and git services (JIRA)]

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

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

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

TS-4066: Memory leaks in gmake check tests

This closes #468


> Memory leaks in gmake check tests
> -
>
> Key: TS-4066
> URL: https://issues.apache.org/jira/browse/TS-4066
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Tests
>Affects Versions: 6.0.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>




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

[jira] [Commented] (TS-4197) Add memory debugging

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4197:


GitHub user PSUdaemon opened a pull request:

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

TS-4197: Add memory debugging



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

$ git pull https://github.com/PSUdaemon/trafficserver memory_debug

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

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


commit 6c345e8a97078beb58ece0f8d1e1068f7b169f24
Author: Phil Sorber 
Date:   2016-02-12T04:58:29Z

TS-4197: Add memory debugging




> Add memory debugging
> 
>
> Key: TS-4197
> URL: https://issues.apache.org/jira/browse/TS-4197
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Phil Sorber
>
> We need more debug for things like hugepage allocation and freelists



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

[jira] [Updated] (TS-4197) Add memory debugging

[Phil Sorber (JIRA)]

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

Phil Sorber updated TS-4197:

Fix Version/s: 6.2.0

> Add memory debugging
> 
>
> Key: TS-4197
> URL: https://issues.apache.org/jira/browse/TS-4197
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Phil Sorber
>Assignee: Leif Hedstrom
> Fix For: 6.2.0
>
>
> We need more debug for things like hugepage allocation and freelists



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

[jira] [Updated] (TS-4197) Add memory debugging

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4197:
--
Assignee: Phil Sorber  (was: Leif Hedstrom)

> Add memory debugging
> 
>
> Key: TS-4197
> URL: https://issues.apache.org/jira/browse/TS-4197
> Project: Traffic Server
>  Issue Type: Improvement
>Reporter: Phil Sorber
>Assignee: Phil Sorber
> Fix For: 6.2.0
>
>
> We need more debug for things like hugepage allocation and freelists



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

[jira] [Commented] (TS-4191) Typo of debug tags setting name in Developer Guide

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4191:


Github user asfgit closed the pull request at:

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


> Typo of debug tags setting name in Developer Guide
> --
>
> Key: TS-4191
> URL: https://issues.apache.org/jira/browse/TS-4191
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: Docs
>Reporter: Eric Sproul
>Assignee: James Peach
>Priority: Trivial
> Fix For: 6.2.0
>
>
> On the page about Debug Tags, the configuration setting is listed as 
> {{proxy.config.diag.debug.tags}} where it should be "diags" (plural).



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

[jira] [Commented] (TS-3863) Add support for ASAN leak detection

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom commented on TS-3863:
---

[~bcall] should we back port this to 6.1.2 ?

> Add support for ASAN leak detection
> ---
>
> Key: TS-3863
> URL: https://issues.apache.org/jira/browse/TS-3863
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.2.0
>
>
> We will need to call exit() instead of _exit() and fix all the coredumps that 
> happen when objects are being cleaned up.



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

[jira] [Resolved] (TS-4191) Typo of debug tags setting name in Developer Guide

[James Peach (JIRA)]

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

James Peach resolved TS-4191.
-
   Resolution: Fixed
Fix Version/s: 6.2.0

> Typo of debug tags setting name in Developer Guide
> --
>
> Key: TS-4191
> URL: https://issues.apache.org/jira/browse/TS-4191
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: Docs
>Reporter: Eric Sproul
>Assignee: James Peach
>Priority: Trivial
> Fix For: 6.2.0
>
>
> On the page about Debug Tags, the configuration setting is listed as 
> {{proxy.config.diag.debug.tags}} where it should be "diags" (plural).



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

[jira] [Assigned] (TS-4191) Typo of debug tags setting name in Developer Guide

[James Peach (JIRA)]

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

James Peach reassigned TS-4191:
---

Assignee: James Peach

> Typo of debug tags setting name in Developer Guide
> --
>
> Key: TS-4191
> URL: https://issues.apache.org/jira/browse/TS-4191
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Documentation
>Affects Versions: Docs
>Reporter: Eric Sproul
>Assignee: James Peach
>Priority: Trivial
> Fix For: 6.2.0
>
>
> On the page about Debug Tags, the configuration setting is listed as 
> {{proxy.config.diag.debug.tags}} where it should be "diags" (plural).



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

[jira] [Commented] (TS-4192) Coredump in HPACK encoding

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-4192:


I have been looking at this one for few days now.  I added some extra code to 
print out the pointer value of the mime_hdr_field_find() call in 
mime_hdr_field_detach() if prev is NULL.

{code}
1579if (prev == NULL)
1580  printf("first: %p\n", first);
{code}

It doesn't look like this is a valid header filed and the names doesn't match 
what we are trying to add "Via" or what we are trying to delete in the call to 
mime_hdr_field_detach() "Date".
{code}
first: 0x61d002955578
(gdb) p *(MIMEField *)0x61d002955578
$5 = {m_ptr_name = 0x61d002f5e4b2 "pts1.mm.bing.netts1.mmXXX",
  m_ptr_value = 0x61d002f5e4bf "netts1.mm.bing.nethttpthts1.mm.bing.nXXX", 
m_next_dup = 0x0, m_wks_idx = 10,
  m_len_name = 13, m_len_value = 23, m_n_v_raw_printable = 0 '\000', 
m_n_v_raw_printable_pad = 0 '\000', m_readiness = 3 '\003', m_flags = 3 '\003'}
(gdb) p *field
$10 = {
  m_ptr_name = 0x62100184fd20 "DateFri, 29 Jan 2016 23:43:53 
GMTAge1042573Content-Length1038Viahttp/1.0 c4.ycs.ne1.yahoo.com 
(ApacheTrafficServer [cRs f ]), https/1.1 l28.ycs.sjb.yahoo.com 
(ApacheTrafficServer [cRs f ])Last-Modifie"...,
  m_ptr_value = 0x62100184fd24 "Fri, 29 Jan 2016 23:43:53 
GMTAge1042573Content-Length1038Viahttp/1.0 c4.ycs.ne1.yahoo.com 
(ApacheTrafficServer [cRs f ]), https/1.1 l28.ycs.sjb.yahoo.com 
(ApacheTrafficServer [cRs f ])Last-ModifiedTue"..., m_next_dup = 
0x629002954e88, m_wks_idx = 23, m_len_name = 4, m_len_value = 29, 
m_n_v_raw_printable = 0 '\000', m_n_v_raw_printable_pad = 0 '\000',
  m_readiness = 2 '\002', m_flags = 0 '\000'}
{code}

> Coredump in HPACK encoding
> --
>
> Key: TS-4192
> URL: https://issues.apache.org/jira/browse/TS-4192
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 6.1.1
>Reporter: Bryan Call
>
> {code}
> #0  0x00972f44 in mime_hdr_field_detach (mh=0x61d002955508, 
> field=0x629002954de8, detach_all_dups=) at MIME.cc:1582
> name_length = 
> prev = 0x0
> first = 
> next_dup = 
> #1  0x00976daa in mime_hdr_field_delete (heap=0x61d002955480, 
> mh=0x61d002955508, field=field@entry=0x629002954de8, 
> delete_all_dups=delete_all_dups@entry=false) at MIME.cc:1631
> No locals.
> #2  0x00844c6d in field_delete (delete_all_dups=false, 
> field=0x629002954de8, this=) at ../../proxy/hdrs/MIME.h:1169
> No locals.
> #3  Http2DynamicTable::add_header_field (this=0x607000fa8b60, 
> field=) at HPACK.cc:307
> last_field = 0x629002954de8
> new_field = 0x629002954de8
> name = 0x62809e18 "Via"
> value = 0x625009705142 "http/1.0 c1.ycs.ne1.yahoo.com 
> (ApacheTrafficServer [cRs f ]), https/1.1 l28.ycs.sjb.yahoo.com 
> (ApacheTrafficServer [cRs f ])\r\nServer: ATS\r\nConnection: 
> keep-alive\r\n\r\n", '\276' ...
> header_size = 
> #4  0x00845112 in add_header_field_to_dynamic_table (field= out>, this=) at HPACK.cc:253
> No locals.
> #5  encode_literal_header_field_with_indexed_name 
> (buf_start=buf_start@entry=0x7fffedda2487 , 
> buf_end=buf_end@entry=0x7fffedda6437 "", header=...,
> index=, indexing_table=..., 
> type=type@entry=HPACK_FIELD_INDEXED_LITERAL) at HPACK.cc:527
> p = 0x7fffedda2487 
> len = 
> prefix = 0 '\000'
> flag = 0 '\000'
> value = 
> __FUNCTION__ = "encode_literal_header_field_with_indexed_name"
> #6  0x0080a8ca in http2_write_header_field 
> (out=out@entry=0x7fffedda2487 , 
> end=end@entry=0x7fffedda6437 "", header=..., indexing_table=...) at 
> HTTP2.cc:509
> field_type = HPACK_FIELD_INDEXED_LITERAL
> name = 
> #7  0x0080c616 in http2_write_header_fragment 
> (in=in@entry=0x61634340, field_iter=..., out=out@entry=0x7fffedda2441 
> "\354l\226\320z\276\224\020T\276R( \005\265",
> out_len=out_len@entry=16374, indexing_table=..., cont=@0x7fffedda2300: 
> false) at HTTP2.cc:592
> name = 0x62809e18 "Via"
> p = 0x7fffedda2487 
> end = 0x7fffedda6437 ""
> len = 
> field = 0x61d0052550a8
> #8  0x008272a0 in Http2ConnectionState::send_headers_frame 
> (this=this@entry=0x61818ee8, fetch_sm=) at 
> Http2ConnectionState.cc:1009
> type = HTTP2_FRAME_TYPE_HEADERS
> __FUNCTION__ = "send_headers_frame"
> buf_len = 16375
> payload_length = 
> flags = 0 '\000'
> stream = 0x60f3e890
> resp_header = 0x61634340
> #9  0x008388db in Http2ConnectionState::main_event_handler 
> (this=0x61818ee8, event=-2, edata=) at 
> Http2ConnectionState.cc:779
> fetch_sm = 
> __FUNCTION__ = "main_event_handler"
> {code}



--

[jira] [Comment Edited] (TS-4192) Coredump in HPACK encoding

[Bryan Call (JIRA)]

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

Bryan Call edited comment on TS-4192 at 2/11/16 5:49 PM:
-

I have been looking at this one for few days now.  I added some extra code to 
print out the pointer value of the mime_hdr_field_find() call in 
mime_hdr_field_detach() if prev is NULL.

{code}
1579if (prev == NULL)
1580  printf("first: %p\n", first);
{code}

It doesn't look like this is a valid header filed and the name doesn't match 
what we are trying to add "Via" or what we are trying to delete in the call to 
mime_hdr_field_detach() "Date".
{code}
first: 0x61d002955578
(gdb) p *(MIMEField *)0x61d002955578
$5 = {m_ptr_name = 0x61d002f5e4b2 "pts1.mm.bing.netts1.mmXXX",
  m_ptr_value = 0x61d002f5e4bf "netts1.mm.bing.nethttpthts1.mm.bing.nXXX", 
m_next_dup = 0x0, m_wks_idx = 10,
  m_len_name = 13, m_len_value = 23, m_n_v_raw_printable = 0 '\000', 
m_n_v_raw_printable_pad = 0 '\000', m_readiness = 3 '\003', m_flags = 3 '\003'}
(gdb) p *field
$10 = {
  m_ptr_name = 0x62100184fd20 "DateFri, 29 Jan 2016 23:43:53 
GMTAge1042573Content-Length1038Viahttp/1.0 c4.ycs.ne1.yahoo.com 
(ApacheTrafficServer [cRs f ]), https/1.1 l28.ycs.sjb.yahoo.com 
(ApacheTrafficServer [cRs f ])Last-Modifie"...,
  m_ptr_value = 0x62100184fd24 "Fri, 29 Jan 2016 23:43:53 
GMTAge1042573Content-Length1038Viahttp/1.0 c4.ycs.ne1.yahoo.com 
(ApacheTrafficServer [cRs f ]), https/1.1 l28.ycs.sjb.yahoo.com 
(ApacheTrafficServer [cRs f ])Last-ModifiedTue"..., m_next_dup = 
0x629002954e88, m_wks_idx = 23, m_len_name = 4, m_len_value = 29, 
m_n_v_raw_printable = 0 '\000', m_n_v_raw_printable_pad = 0 '\000',
  m_readiness = 2 '\002', m_flags = 0 '\000'}
{code}


was (Author: bcall):
I have been looking at this one for few days now.  I added some extra code to 
print out the pointer value of the mime_hdr_field_find() call in 
mime_hdr_field_detach() if prev is NULL.

{code}
1579if (prev == NULL)
1580  printf("first: %p\n", first);
{code}

It doesn't look like this is a valid header filed and the names doesn't match 
what we are trying to add "Via" or what we are trying to delete in the call to 
mime_hdr_field_detach() "Date".
{code}
first: 0x61d002955578
(gdb) p *(MIMEField *)0x61d002955578
$5 = {m_ptr_name = 0x61d002f5e4b2 "pts1.mm.bing.netts1.mmXXX",
  m_ptr_value = 0x61d002f5e4bf "netts1.mm.bing.nethttpthts1.mm.bing.nXXX", 
m_next_dup = 0x0, m_wks_idx = 10,
  m_len_name = 13, m_len_value = 23, m_n_v_raw_printable = 0 '\000', 
m_n_v_raw_printable_pad = 0 '\000', m_readiness = 3 '\003', m_flags = 3 '\003'}
(gdb) p *field
$10 = {
  m_ptr_name = 0x62100184fd20 "DateFri, 29 Jan 2016 23:43:53 
GMTAge1042573Content-Length1038Viahttp/1.0 c4.ycs.ne1.yahoo.com 
(ApacheTrafficServer [cRs f ]), https/1.1 l28.ycs.sjb.yahoo.com 
(ApacheTrafficServer [cRs f ])Last-Modifie"...,
  m_ptr_value = 0x62100184fd24 "Fri, 29 Jan 2016 23:43:53 
GMTAge1042573Content-Length1038Viahttp/1.0 c4.ycs.ne1.yahoo.com 
(ApacheTrafficServer [cRs f ]), https/1.1 l28.ycs.sjb.yahoo.com 
(ApacheTrafficServer [cRs f ])Last-ModifiedTue"..., m_next_dup = 
0x629002954e88, m_wks_idx = 23, m_len_name = 4, m_len_value = 29, 
m_n_v_raw_printable = 0 '\000', m_n_v_raw_printable_pad = 0 '\000',
  m_readiness = 2 '\002', m_flags = 0 '\000'}
{code}

> Coredump in HPACK encoding
> --
>
> Key: TS-4192
> URL: https://issues.apache.org/jira/browse/TS-4192
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 6.1.1
>Reporter: Bryan Call
>
> {code}
> #0  0x00972f44 in mime_hdr_field_detach (mh=0x61d002955508, 
> field=0x629002954de8, detach_all_dups=) at MIME.cc:1582
> name_length = 
> prev = 0x0
> first = 
> next_dup = 
> #1  0x00976daa in mime_hdr_field_delete (heap=0x61d002955480, 
> mh=0x61d002955508, field=field@entry=0x629002954de8, 
> delete_all_dups=delete_all_dups@entry=false) at MIME.cc:1631
> No locals.
> #2  0x00844c6d in field_delete (delete_all_dups=false, 
> field=0x629002954de8, this=) at ../../proxy/hdrs/MIME.h:1169
> No locals.
> #3  Http2DynamicTable::add_header_field (this=0x607000fa8b60, 
> field=) at HPACK.cc:307
> last_field = 0x629002954de8
> new_field = 0x629002954de8
> name = 0x62809e18 "Via"
> value = 0x625009705142 "http/1.0 c1.ycs.ne1.yahoo.com 
> (ApacheTrafficServer [cRs f ]), https/1.1 l28.ycs.sjb.yahoo.com 
> (ApacheTrafficServer [cRs f ])\r\nServer: ATS\r\nConnection: 
> keep-alive\r\n\r\n", '\276' ...
> header_size = 
> #4  0x00845112 in add_header_field_to_dynamic_table (field= out>, this=) at HPACK.cc:253
> No locals.
> #5  encode_literal_header_field_with_indexed_name 
> (buf_start=buf_start@entry=0x7fffedda2487 , 
> 

[jira] [Updated] (TS-4193) Enabling proxy.config.disable_configuration_modification can "lose" metrics via e.g. stats_over_http

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4193:
--
Fix Version/s: 6.2.0

> Enabling proxy.config.disable_configuration_modification can "lose" metrics 
> via e.g. stats_over_http
> 
>
> Key: TS-4193
> URL: https://issues.apache.org/jira/browse/TS-4193
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Manager, Metrics, Plugins
>Reporter: Leif Hedstrom
> Fix For: 6.2.0
>
>
> With normal configs, using stats_over_http, I get e.g.
> {code}
> loki (10:50) 339/0 $ curl -s  http://loki.ogre.com/_bazinga | grep 
> proxy.node.http.user_agent_total
> "proxy.node.http.user_agent_total_request_bytes": "789",
> "proxy.node.http.user_agent_total_response_bytes": "612070",
> {code}
> However, if I disable config write updates 
> (proxy.config.disable_configuration_modification=1), these metrics are no 
> longer producing values via stats_over_http:
> {code}
> loki (10:52) 341/0 $ curl -s  http://loki.ogre.com/_bazinga | grep 
> proxy.node.http.user_agent_total
> "proxy.node.http.user_agent_total_request_bytes": "0",
> "proxy.node.http.user_agent_total_response_bytes": "0",
> {code}
> What's surprising is the according to traffic_ctl, the metrics are fine even 
> with the new config enabled:
> {code}
> loki (10:52) 341/0 $ /opt/ats/bin/traffic_ctl  metric match 
> proxy.node.http.user_agent_total
> proxy.node.http.user_agent_total_request_bytes 1948
> proxy.node.http.user_agent_total_response_bytes 1699917
> {code}
> Maybe these changes interfere with how the stats_over_http plugin uses the 
> lib records iterator?



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

[jira] [Created] (TS-4193) Enabling proxy.config.disable_configuration_modification can "lose" metrics via e.g. stats_over_http

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4193:
-

 Summary: Enabling proxy.config.disable_configuration_modification 
can "lose" metrics via e.g. stats_over_http
 Key: TS-4193
 URL: https://issues.apache.org/jira/browse/TS-4193
 Project: Traffic Server
  Issue Type: Bug
  Components: Manager, Metrics, Plugins
Reporter: Leif Hedstrom


With normal configs, using stats_over_http, I get e.g.

{code}
loki (10:50) 339/0 $ curl -s  http://loki.ogre.com/_bazinga | grep 
proxy.node.http.user_agent_total
"proxy.node.http.user_agent_total_request_bytes": "789",
"proxy.node.http.user_agent_total_response_bytes": "612070",
{code}

However, if I disable config write updates 
(proxy.config.disable_configuration_modification=1), these metrics are no 
longer producing values via stats_over_http:

{code}
loki (10:52) 341/0 $ curl -s  http://loki.ogre.com/_bazinga | grep 
proxy.node.http.user_agent_total
"proxy.node.http.user_agent_total_request_bytes": "0",
"proxy.node.http.user_agent_total_response_bytes": "0",
{code}

What's surprising is the according to traffic_ctl, the metrics are fine even 
with the new config enabled:

{code}
loki (10:52) 341/0 $ /opt/ats/bin/traffic_ctl  metric match 
proxy.node.http.user_agent_total
proxy.node.http.user_agent_total_request_bytes 1948
proxy.node.http.user_agent_total_response_bytes 1699917
{code}

Maybe these changes interfere with how the stats_over_http plugin uses the lib 
records iterator?



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

[jira] [Created] (TS-4194) require LuaJIt in builds

[James Peach (JIRA)]

James Peach created TS-4194:
---

 Summary: require LuaJIt in builds
 Key: TS-4194
 URL: https://issues.apache.org/jira/browse/TS-4194
 Project: Traffic Server
  Issue Type: Improvement
  Components: Lua
Reporter: James Peach


For 7.0 we should always require LuaJIT since increasingly internal features 
will use it.



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

[jira] [Updated] (TS-4194) require LuaJIt in builds

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4194:
--
Fix Version/s: 7.0.0

> require LuaJIt in builds
> 
>
> Key: TS-4194
> URL: https://issues.apache.org/jira/browse/TS-4194
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Lua
>Reporter: James Peach
> Fix For: 7.0.0
>
>
> For 7.0 we should always require LuaJIT since increasingly internal features 
> will use it.



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

[jira] [Comment Edited] (TS-4192) Coredump in HPACK encoding

[Bryan Call (JIRA)]

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

Bryan Call edited comment on TS-4192 at 2/11/16 6:06 PM:
-

I have been looking at this one for few days now.  I added some extra code to 
print out the pointer value of the mime_hdr_field_find() call in 
mime_hdr_field_detach() if prev is NULL.

{code}
1579if (prev == NULL)
1580  printf("first: %p\n", first);
{code}

It doesn't look like this is a valid header filed and the name doesn't match 
what we are trying to  delete in the call to mime_hdr_field_detach() "Date".
{code}
first: 0x61d002955578
(gdb) p *(MIMEField *)0x61d002955578
$5 = {m_ptr_name = 0x61d002f5e4b2 "pts1.mm.bing.netts1.mmXXX",
  m_ptr_value = 0x61d002f5e4bf "netts1.mm.bing.nethttpthts1.mm.bing.nXXX", 
m_next_dup = 0x0, m_wks_idx = 10,
  m_len_name = 13, m_len_value = 23, m_n_v_raw_printable = 0 '\000', 
m_n_v_raw_printable_pad = 0 '\000', m_readiness = 3 '\003', m_flags = 3 '\003'}
(gdb) p *field
$10 = {
  m_ptr_name = 0x62100184fd20 "DateFri, 29 Jan 2016 23:43:53 
GMTAge1042573Content-Length1038Viahttp/1.0 c4.ycs.ne1.yahoo.com 
(ApacheTrafficServer [cRs f ]), https/1.1 l28.ycs.sjb.yahoo.com 
(ApacheTrafficServer [cRs f ])Last-Modifie"...,
  m_ptr_value = 0x62100184fd24 "Fri, 29 Jan 2016 23:43:53 
GMTAge1042573Content-Length1038Viahttp/1.0 c4.ycs.ne1.yahoo.com 
(ApacheTrafficServer [cRs f ]), https/1.1 l28.ycs.sjb.yahoo.com 
(ApacheTrafficServer [cRs f ])Last-ModifiedTue"..., m_next_dup = 
0x629002954e88, m_wks_idx = 23, m_len_name = 4, m_len_value = 29, 
m_n_v_raw_printable = 0 '\000', m_n_v_raw_printable_pad = 0 '\000',
  m_readiness = 2 '\002', m_flags = 0 '\000'}
{code}


was (Author: bcall):
I have been looking at this one for few days now.  I added some extra code to 
print out the pointer value of the mime_hdr_field_find() call in 
mime_hdr_field_detach() if prev is NULL.

{code}
1579if (prev == NULL)
1580  printf("first: %p\n", first);
{code}

It doesn't look like this is a valid header filed and the name doesn't match 
what we are trying to add "Via" or what we are trying to delete in the call to 
mime_hdr_field_detach() "Date".
{code}
first: 0x61d002955578
(gdb) p *(MIMEField *)0x61d002955578
$5 = {m_ptr_name = 0x61d002f5e4b2 "pts1.mm.bing.netts1.mmXXX",
  m_ptr_value = 0x61d002f5e4bf "netts1.mm.bing.nethttpthts1.mm.bing.nXXX", 
m_next_dup = 0x0, m_wks_idx = 10,
  m_len_name = 13, m_len_value = 23, m_n_v_raw_printable = 0 '\000', 
m_n_v_raw_printable_pad = 0 '\000', m_readiness = 3 '\003', m_flags = 3 '\003'}
(gdb) p *field
$10 = {
  m_ptr_name = 0x62100184fd20 "DateFri, 29 Jan 2016 23:43:53 
GMTAge1042573Content-Length1038Viahttp/1.0 c4.ycs.ne1.yahoo.com 
(ApacheTrafficServer [cRs f ]), https/1.1 l28.ycs.sjb.yahoo.com 
(ApacheTrafficServer [cRs f ])Last-Modifie"...,
  m_ptr_value = 0x62100184fd24 "Fri, 29 Jan 2016 23:43:53 
GMTAge1042573Content-Length1038Viahttp/1.0 c4.ycs.ne1.yahoo.com 
(ApacheTrafficServer [cRs f ]), https/1.1 l28.ycs.sjb.yahoo.com 
(ApacheTrafficServer [cRs f ])Last-ModifiedTue"..., m_next_dup = 
0x629002954e88, m_wks_idx = 23, m_len_name = 4, m_len_value = 29, 
m_n_v_raw_printable = 0 '\000', m_n_v_raw_printable_pad = 0 '\000',
  m_readiness = 2 '\002', m_flags = 0 '\000'}
{code}

> Coredump in HPACK encoding
> --
>
> Key: TS-4192
> URL: https://issues.apache.org/jira/browse/TS-4192
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 6.1.1
>Reporter: Bryan Call
>
> {code}
> #0  0x00972f44 in mime_hdr_field_detach (mh=0x61d002955508, 
> field=0x629002954de8, detach_all_dups=) at MIME.cc:1582
> name_length = 
> prev = 0x0
> first = 
> next_dup = 
> #1  0x00976daa in mime_hdr_field_delete (heap=0x61d002955480, 
> mh=0x61d002955508, field=field@entry=0x629002954de8, 
> delete_all_dups=delete_all_dups@entry=false) at MIME.cc:1631
> No locals.
> #2  0x00844c6d in field_delete (delete_all_dups=false, 
> field=0x629002954de8, this=) at ../../proxy/hdrs/MIME.h:1169
> No locals.
> #3  Http2DynamicTable::add_header_field (this=0x607000fa8b60, 
> field=) at HPACK.cc:307
> last_field = 0x629002954de8
> new_field = 0x629002954de8
> name = 0x62809e18 "Via"
> value = 0x625009705142 "http/1.0 c1.ycs.ne1.yahoo.com 
> (ApacheTrafficServer [cRs f ]), https/1.1 l28.ycs.sjb.yahoo.com 
> (ApacheTrafficServer [cRs f ])\r\nServer: ATS\r\nConnection: 
> keep-alive\r\n\r\n", '\276' ...
> header_size = 
> #4  0x00845112 in add_header_field_to_dynamic_table (field= out>, this=) at HPACK.cc:253
> No locals.
> #5  encode_literal_header_field_with_indexed_name 
> (buf_start=buf_start@entry=0x7fffedda2487 , 
> buf_end=buf_end@entry=0x7fffedda6437 "", 

[jira] [Updated] (TS-4195) out of traffic_manager causes a double free in traffic_server

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4195:
--
Fix Version/s: 6.2.0

> out of traffic_manager causes a double free in traffic_server
> -
>
> Key: TS-4195
> URL: https://issues.apache.org/jira/browse/TS-4195
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Reporter: Leif Hedstrom
> Fix For: 6.2.0
>
>
> While testing stuff, I was running traffic_manager from command line, and 
> then I get a crash from traffic_server:
> {code}
> root@loki 407/0 # ./bin/traffic_manager
> [E. Mgmt] log ==> [TrafficManager] using root directory '/opt/ats'
> traffic_server: using root directory '/opt/ats'
> ^C[TrafficManager] ==> Cleaning up and reissuing signal #2
> traffic_server: Interrupt (Signal sent by the kernel 0 0)
> 9083 sent by kill()*** Error in `/opt/ats/bin/traffic_server': corrupted 
> double-linked list: 0x028f8940 ***
> === Backtrace: =
> /lib64/libc.so.6(+0x77da5)[0x2ad58f3fcda5]
> /lib64/libc.so.6(+0x80c06)[0x2ad58f405c06]
> /lib64/libc.so.6(cfree+0x4c)[0x2ad58f408cac]
> /lib64/libc.so.6(+0x39685)[0x2ad58f3be685]
> /lib64/libc.so.6(+0x396a5)[0x2ad58f3be6a5]
> /opt/ats/bin/traffic_server[0x4e300atraffic_server: Segmentation fault 
> (Address not mapped to object [0x55b02140])
> traffic_server - STACK TRACE:
> /lib64/libc.so.6(nanosleep+0x2d)[0x2ad58f44d7ad]
> /opt/ats/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4abece]
> /lib64/libpthread.so.0(+0x109f0)[0x2ad58e3709f0]
> /lib64/libc.so.6(sleep+0xd4)[0x2ad58f44d644]
> /opt/ats/bin/traffic_server(_Z19startProcessManagerPv+0xb1)[0x69b8a1]
> /lib64/libpthread.so.0(+0x760a)[0x2ad58e36760a]
> /lib64/libc.so.6(clone+0x6d)[0x2ad58f487a4d]
> === Memory map: 
> /lib64/libc.so.6(+0x395ad)[0x2ad58f3be5ad]
> 0040-008a6000 r-xp  00:24 1775473
> /opt/ats/bin/traffic_server
> 00aa6000-00ab3000 r--p 004a6000 00:24 1775473
> /opt/ats/bin/traffic_server
> 00ab3000-00ab9000 rw-p 004b3000 00:24 1775473
> /opt/ats/bin/traffic_server
> 00ab9000-01097000 rw-p  00:00 0
> 028dd000-02cb9000 rw-p  00:00 0  
> [heap]
> 2ad58c52c000-2ad58c54d000 r-xp  00:24 1389899
> /usr/lib64/ld-2.22.so
> 2ad58c54d000-2ad58c55 rw-p  00:00 0
> 2ad58c55-2ad58c56 rwxp  00:00 0
> 2ad58c56b000-2ad58c6ed000 rw-p  00:00 0
> 2ad58c6ed000-2ad58c6fd000 rwxp  00:00 0
> 2ad58c6fd000-2ad58c748000 rw-p  00:00 0
> 2ad58c74c000-2ad58c74d000 r--p 0002 00:24 1389899
> /usr/lib64/ld-2.22.so
> 2ad58c74d000-2ad58c74e000 rw-p 00021000 00:24 1389899
> /usr/lib64/ld-2.22.so
> 2ad58c74e000-2ad58c74f000 rw-p  00:00 0
> 2ad58c74f000-2ad58c79 r-xp  00:24 1775306
> /opt/ats/lib/libtsutil.so.6.2.0
> 2ad58c79-2ad58c99 ---p 00041000 00:24 1775306
> /opt/ats/lib/libtsutil.so.6.2.0
> 2ad58c99-2ad58c991000 r--p 00041000 00:24 1775306
> /opt/ats/lib/libtsutil.so.6.2.0
> 2ad58c991000-2ad58c993000 rw-p 00042000 00:24 1775306
> /opt/ats/lib/libtsutil.so.6.2.0
> 2ad58c993000-2ad58c994000 rw-p  00:00 0
> 2ad58c994000-2ad58c9cb000 r-xp  00:24 1393339
> /usr/lib64/libhwloc.so.5.6.6
> 2ad58c9cb000-2ad58cbcb000 ---p 00037000 00:24 1393339
> /usr/lib64/libhwloc.so.5.6.6
> 2ad58cbcb000-2ad58cbcc000 r--p 00037000 00:24 1393339
> /usr/lib64/libhwloc.so.5.6.6
> 2ad58cbcc000-2ad58cbcd000 rw-p 00038000 00:24 1393339
> /usr/lib64/libhwloc.so.5.6.6
> 2ad58cbcd000-2ad58cd77000 r-xp  00:24 1441754
> /usr/lib64/libtcl8.6.so
> 2ad58cd77000-2ad58cf77000 ---p 001aa000 00:24 1441754  
> /lib64/libc.so.6(  /usr/lib64/libtcl8.6.so
> 2ad58cf77000-2ad58cf86000 r--p 001aa000 00:24 1441754
> /usr/lib64/libtcl8.6.so
> 2ad58cf86000-2ad58cf87000 rw-p 001b9000 00:24 1441754
> /usr/lib64/libtcl8.6.so
> 2ad58cf87000-2ad58cf88000 rw-p  00:00 0
> 2ad58cf88000-2ad58cf9f000 r-xp  00:24 1389936
> /usr/lib64/libresolv-2.22.so
> 2ad58cf9f000-2ad58d19f000 ---p 00017000 00:24 1389936
> /usr/lib64/libresolv-2.22.so
> 2ad58d19f000-2ad58d1a r--p 00017000 00:24 1389936
> /usr/lib64/libresolv-2.22.so
> 2ad58d1a-2ad58d1a1000 rw-p 00018000 00:24 1389936
> /usr/lib64/libresolv-2.22.so
> 2ad58d1a1000-2ad58d1a3000 rw-p  00:00 0
> 2ad58d1a3000-2ad58d212000 r-xp  00:24 

[jira] [Created] (TS-4195) out of traffic_manager causes a double free in traffic_server

[Leif Hedstrom (JIRA)]

Leif Hedstrom created TS-4195:
-

 Summary: out of traffic_manager causes a double free in 
traffic_server
 Key: TS-4195
 URL: https://issues.apache.org/jira/browse/TS-4195
 Project: Traffic Server
  Issue Type: Bug
  Components: Core
Reporter: Leif Hedstrom


While testing stuff, I was running traffic_manager from command line, and then 
I get a crash from traffic_server:

{code}
root@loki 407/0 # ./bin/traffic_manager
[E. Mgmt] log ==> [TrafficManager] using root directory '/opt/ats'
traffic_server: using root directory '/opt/ats'
^C[TrafficManager] ==> Cleaning up and reissuing signal #2
traffic_server: Interrupt (Signal sent by the kernel 0 0)

9083 sent by kill()*** Error in `/opt/ats/bin/traffic_server': corrupted 
double-linked list: 0x028f8940 ***
=== Backtrace: =
/lib64/libc.so.6(+0x77da5)[0x2ad58f3fcda5]
/lib64/libc.so.6(+0x80c06)[0x2ad58f405c06]
/lib64/libc.so.6(cfree+0x4c)[0x2ad58f408cac]
/lib64/libc.so.6(+0x39685)[0x2ad58f3be685]
/lib64/libc.so.6(+0x396a5)[0x2ad58f3be6a5]
/opt/ats/bin/traffic_server[0x4e300atraffic_server: Segmentation fault (Address 
not mapped to object [0x55b02140])
traffic_server - STACK TRACE:
/lib64/libc.so.6(nanosleep+0x2d)[0x2ad58f44d7ad]
/opt/ats/bin/traffic_server(_Z19crash_logger_invokeiP9siginfo_tPv+0x8e)[0x4abece]
/lib64/libpthread.so.0(+0x109f0)[0x2ad58e3709f0]
/lib64/libc.so.6(sleep+0xd4)[0x2ad58f44d644]
/opt/ats/bin/traffic_server(_Z19startProcessManagerPv+0xb1)[0x69b8a1]
/lib64/libpthread.so.0(+0x760a)[0x2ad58e36760a]
/lib64/libc.so.6(clone+0x6d)[0x2ad58f487a4d]
=== Memory map: 
/lib64/libc.so.6(+0x395ad)[0x2ad58f3be5ad]
0040-008a6000 r-xp  00:24 1775473
/opt/ats/bin/traffic_server
00aa6000-00ab3000 r--p 004a6000 00:24 1775473
/opt/ats/bin/traffic_server
00ab3000-00ab9000 rw-p 004b3000 00:24 1775473
/opt/ats/bin/traffic_server
00ab9000-01097000 rw-p  00:00 0
028dd000-02cb9000 rw-p  00:00 0  [heap]
2ad58c52c000-2ad58c54d000 r-xp  00:24 1389899
/usr/lib64/ld-2.22.so
2ad58c54d000-2ad58c55 rw-p  00:00 0
2ad58c55-2ad58c56 rwxp  00:00 0
2ad58c56b000-2ad58c6ed000 rw-p  00:00 0
2ad58c6ed000-2ad58c6fd000 rwxp  00:00 0
2ad58c6fd000-2ad58c748000 rw-p  00:00 0
2ad58c74c000-2ad58c74d000 r--p 0002 00:24 1389899
/usr/lib64/ld-2.22.so
2ad58c74d000-2ad58c74e000 rw-p 00021000 00:24 1389899
/usr/lib64/ld-2.22.so
2ad58c74e000-2ad58c74f000 rw-p  00:00 0
2ad58c74f000-2ad58c79 r-xp  00:24 1775306
/opt/ats/lib/libtsutil.so.6.2.0
2ad58c79-2ad58c99 ---p 00041000 00:24 1775306
/opt/ats/lib/libtsutil.so.6.2.0
2ad58c99-2ad58c991000 r--p 00041000 00:24 1775306
/opt/ats/lib/libtsutil.so.6.2.0
2ad58c991000-2ad58c993000 rw-p 00042000 00:24 1775306
/opt/ats/lib/libtsutil.so.6.2.0
2ad58c993000-2ad58c994000 rw-p  00:00 0
2ad58c994000-2ad58c9cb000 r-xp  00:24 1393339
/usr/lib64/libhwloc.so.5.6.6
2ad58c9cb000-2ad58cbcb000 ---p 00037000 00:24 1393339
/usr/lib64/libhwloc.so.5.6.6
2ad58cbcb000-2ad58cbcc000 r--p 00037000 00:24 1393339
/usr/lib64/libhwloc.so.5.6.6
2ad58cbcc000-2ad58cbcd000 rw-p 00038000 00:24 1393339
/usr/lib64/libhwloc.so.5.6.6
2ad58cbcd000-2ad58cd77000 r-xp  00:24 1441754
/usr/lib64/libtcl8.6.so
2ad58cd77000-2ad58cf77000 ---p 001aa000 00:24 1441754  
/lib64/libc.so.6(  /usr/lib64/libtcl8.6.so
2ad58cf77000-2ad58cf86000 r--p 001aa000 00:24 1441754
/usr/lib64/libtcl8.6.so
2ad58cf86000-2ad58cf87000 rw-p 001b9000 00:24 1441754
/usr/lib64/libtcl8.6.so
2ad58cf87000-2ad58cf88000 rw-p  00:00 0
2ad58cf88000-2ad58cf9f000 r-xp  00:24 1389936
/usr/lib64/libresolv-2.22.so
2ad58cf9f000-2ad58d19f000 ---p 00017000 00:24 1389936
/usr/lib64/libresolv-2.22.so
2ad58d19f000-2ad58d1a r--p 00017000 00:24 1389936
/usr/lib64/libresolv-2.22.so
2ad58d1a-2ad58d1a1000 rw-p 00018000 00:24 1389936
/usr/lib64/libresolv-2.22.so
2ad58d1a1000-2ad58d1a3000 rw-p  00:00 0
2ad58d1a3000-2ad58d212000 r-xp  00:24 1635380
/usr/lib64/libssl.so.1.0.2f
2ad58d212000-2ad58d411000 ---p 0006f000 00:24 1635380
/usr/lib64/libssl.so.1.0.2f
2ad58d411000-2ad58d416000 r--p 0006e000 00:24 1635380
/usr/lib64/libssl.so.1.0.2f
2ad58d416000-2ad58d41d000 rw-p 00073000 00:24 1635380
/usr/lib64/libssl.so.1.0.2f
2ad58d41d000-2ad58d64d000 r-xp  00:24 

[jira] [Commented] (TS-4192) Coredump in HPACK encoding

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-4192:


It looks like there are a bunch of Date headers being stored in the mime 
headers.
{code}
(gdb) p 
*field->m_next_dup->m_next_dup->m_next_dup->m_next_dup->m_next_dup->m_next_dup->m_next_dup->m_next_dup->m_next_dup->m_next_dup->m_next_dup
$36 = {
  m_ptr_name = 0x62100185049c "DateSun, 27 Dec 2015 17:54:01 
GMTAge3914767Content-Length548Last-ModifiedMon, 21 Dec 2015 03:24:44 
GMTContent-EncodinggzipDateMon, 21 Dec 2015 03:24:44 
GMTAge4485323Content-Length416", '\276' ...,
  m_ptr_value = 0x6210018504a0 "Sun, 27 Dec 2015 17:54:01 
GMTAge3914767Content-Length548Last-ModifiedMon, 21 Dec 2015 03:24:44 
GMTContent-EncodinggzipDateMon, 21 Dec 2015 03:24:44 
GMTAge4485323Content-Length416", '\276' ..., m_next_dup = 
0x0, m_wks_idx = 23, m_len_name = 4, m_len_value = 29, m_n_v_raw_printable = 0 
'\000', m_n_v_raw_printable_pad = 0 '\000',
  m_readiness = 2 '\002', m_flags = 0 '\000'}
{code}

> Coredump in HPACK encoding
> --
>
> Key: TS-4192
> URL: https://issues.apache.org/jira/browse/TS-4192
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 6.1.1
>Reporter: Bryan Call
>
> {code}
> #0  0x00972f44 in mime_hdr_field_detach (mh=0x61d002955508, 
> field=0x629002954de8, detach_all_dups=) at MIME.cc:1582
> name_length = 
> prev = 0x0
> first = 
> next_dup = 
> #1  0x00976daa in mime_hdr_field_delete (heap=0x61d002955480, 
> mh=0x61d002955508, field=field@entry=0x629002954de8, 
> delete_all_dups=delete_all_dups@entry=false) at MIME.cc:1631
> No locals.
> #2  0x00844c6d in field_delete (delete_all_dups=false, 
> field=0x629002954de8, this=) at ../../proxy/hdrs/MIME.h:1169
> No locals.
> #3  Http2DynamicTable::add_header_field (this=0x607000fa8b60, 
> field=) at HPACK.cc:307
> last_field = 0x629002954de8
> new_field = 0x629002954de8
> name = 0x62809e18 "Via"
> value = 0x625009705142 "http/1.0 c1.ycs.ne1.yahoo.com 
> (ApacheTrafficServer [cRs f ]), https/1.1 l28.ycs.sjb.yahoo.com 
> (ApacheTrafficServer [cRs f ])\r\nServer: ATS\r\nConnection: 
> keep-alive\r\n\r\n", '\276' ...
> header_size = 
> #4  0x00845112 in add_header_field_to_dynamic_table (field= out>, this=) at HPACK.cc:253
> No locals.
> #5  encode_literal_header_field_with_indexed_name 
> (buf_start=buf_start@entry=0x7fffedda2487 , 
> buf_end=buf_end@entry=0x7fffedda6437 "", header=...,
> index=, indexing_table=..., 
> type=type@entry=HPACK_FIELD_INDEXED_LITERAL) at HPACK.cc:527
> p = 0x7fffedda2487 
> len = 
> prefix = 0 '\000'
> flag = 0 '\000'
> value = 
> __FUNCTION__ = "encode_literal_header_field_with_indexed_name"
> #6  0x0080a8ca in http2_write_header_field 
> (out=out@entry=0x7fffedda2487 , 
> end=end@entry=0x7fffedda6437 "", header=..., indexing_table=...) at 
> HTTP2.cc:509
> field_type = HPACK_FIELD_INDEXED_LITERAL
> name = 
> #7  0x0080c616 in http2_write_header_fragment 
> (in=in@entry=0x61634340, field_iter=..., out=out@entry=0x7fffedda2441 
> "\354l\226\320z\276\224\020T\276R( \005\265",
> out_len=out_len@entry=16374, indexing_table=..., cont=@0x7fffedda2300: 
> false) at HTTP2.cc:592
> name = 0x62809e18 "Via"
> p = 0x7fffedda2487 
> end = 0x7fffedda6437 ""
> len = 
> field = 0x61d0052550a8
> #8  0x008272a0 in Http2ConnectionState::send_headers_frame 
> (this=this@entry=0x61818ee8, fetch_sm=) at 
> Http2ConnectionState.cc:1009
> type = HTTP2_FRAME_TYPE_HEADERS
> __FUNCTION__ = "send_headers_frame"
> buf_len = 16375
> payload_length = 
> flags = 0 '\000'
> stream = 0x60f3e890
> resp_header = 0x61634340
> #9  0x008388db in Http2ConnectionState::main_event_handler 
> (this=0x61818ee8, event=-2, edata=) at 
> Http2ConnectionState.cc:779
> fetch_sm = 
> __FUNCTION__ = "main_event_handler"
> {code}



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

[jira] [Updated] (TS-3863) Add support for ASAN leak detection

[Bryan Call (JIRA)]

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

Bryan Call updated TS-3863:
---
Backport to Version: 6.1.2

> Add support for ASAN leak detection
> ---
>
> Key: TS-3863
> URL: https://issues.apache.org/jira/browse/TS-3863
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.2.0
>
>
> We will need to call exit() instead of _exit() and fix all the coredumps that 
> happen when objects are being cleaned up.



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

[jira] [Commented] (TS-3863) Add support for ASAN leak detection

[Bryan Call (JIRA)]

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

Bryan Call commented on TS-3863:


Sure, it is a nice feature to have.

> Add support for ASAN leak detection
> ---
>
> Key: TS-3863
> URL: https://issues.apache.org/jira/browse/TS-3863
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Core
>Reporter: Bryan Call
>Assignee: Bryan Call
>  Labels: yahoo
> Fix For: 6.2.0
>
>
> We will need to call exit() instead of _exit() and fix all the coredumps that 
> happen when objects are being cleaned up.



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

[jira] [Commented] (TS-4181) Memory leak in aio threads when shutting down

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4181:


Github user zwoop commented on the pull request:

https://github.com/apache/trafficserver/pull/463#issuecomment-182969455
  
+1


> Memory leak in aio threads when shutting down
> -
>
> Key: TS-4181
> URL: https://issues.apache.org/jira/browse/TS-4181
> Project: Traffic Server
>  Issue Type: Bug
>  Components: Core
>Affects Versions: 6.1.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>
> {code}
> Direct leak of 504 byte(s) in 7 object(s) allocated from:
> #0 0x7fcf4c5e7872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0xbe4c44 in aio_init_fildes 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:252
> #2 0xbe5ccf in aio_queue_req 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:358
> #3 0xbe5f02 in ink_aio_read(AIOCallback*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:426
> #4 0xb1d1fa in CacheDisk::open(char*, long, long, int, int, bool) 
> /home/bcall/dev/apache/trafficserver/iocore/cache/CacheDisk.cc:76
> #5 0xaddc69 in CacheProcessor::start_internal(int) 
> /home/bcall/dev/apache/trafficserver/iocore/cache/Cache.cc:720
> #6 0x49511f in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1808
> #7 0x7fcf4952457f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> Direct leak of 72 byte(s) in 1 object(s) allocated from:
> #0 0x7fcf4c5e7872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0xbe4ebc in aio_init_fildes 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:250
> #2 0xbe5ccf in aio_queue_req 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:358
> #3 0xbe5f02 in ink_aio_read(AIOCallback*, int) 
> /home/bcall/dev/apache/trafficserver/iocore/aio/AIO.cc:426
> #4 0xb1d1fa in CacheDisk::open(char*, long, long, int, int, bool) 
> /home/bcall/dev/apache/trafficserver/iocore/cache/CacheDisk.cc:76
> #5 0xaddc69 in CacheProcessor::start_internal(int) 
> /home/bcall/dev/apache/trafficserver/iocore/cache/Cache.cc:720
> #6 0x49511f in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1808
> #7 0x7fcf4952457f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> {code}



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

[jira] [Commented] (TS-4178) Memory leak in SplitDNSConfig when shutting down

[ASF GitHub Bot (JIRA)]

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

ASF GitHub Bot commented on TS-4178:


Github user zwoop commented on the pull request:

https://github.com/apache/trafficserver/pull/464#issuecomment-182975244
  
I don't quite understand it, but it seems fine and correct, and if it shuts 
up Stroustrup, +1!


> Memory leak in SplitDNSConfig when shutting down
> 
>
> Key: TS-4178
> URL: https://issues.apache.org/jira/browse/TS-4178
> Project: Traffic Server
>  Issue Type: Bug
>  Components: DNS
>Affects Versions: 6.1.0
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.2.0
>
>
> {code}
> =
> ==7628==ERROR: LeakSanitizer: detected memory leaks
> Direct leak of 8 byte(s) in 1 object(s) allocated from:
> #0 0x7f27d1b01872 in operator new(unsigned long) 
> (/lib64/libasan.so.2+0x99872)
> #1 0xa1a1c3 in SplitDNSConfig::startup() 
> /home/bcall/dev/apache/trafficserver/iocore/dns/SplitDNS.cc:133
> #2 0x494e59 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1767
> #3 0x7f27cea3e57f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> Indirect leak of 80 byte(s) in 1 object(s) allocated from:
> #0 0x7f4dee606e72 in memalign (/lib64/libasan.so.2+0x98e72)
> #1 0x7f4dee337d91 in ats_memalign 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:112
> #2 0x7f4dee338cb2 in ink_freelist_new 
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_queue.cc:181
> #3 0xa1a1e0 in ClassAllocator::alloc() 
> ../../lib/ts/Allocator.h:122
> #4 0xa1a1e0 in new_ProxyMutex() ../../iocore/eventsystem/I_Lock.h:555
> #5 0xa1a1e0 in SplitDNSConfig::startup() ../../mgmt/ProxyConfig.h:121
> #6 0x494e59 in main 
> /home/bcall/dev/apache/trafficserver/proxy/Main.cc:1767
> #7 0x7f4deb54457f in __libc_start_main (/lib64/libc.so.6+0x2057f)
> {code}



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

[jira] [Commented] (TS-2446) Document how to document

[ASF subversion and git services (JIRA)]

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

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

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

TS-2446: dev guide section on documenting plugins


> Document how to document
> 
>
> Key: TS-2446
> URL: https://issues.apache.org/jira/browse/TS-2446
> Project: Traffic Server
>  Issue Type: Improvement
>  Components: Documentation
>Reporter: Miles Libbey
>Assignee: Jon Sime
> Fix For: Docs
>
>
> Our documentation system has a very large learning curve.  Writers need to 
> learn reStructured text and Sphinx and our unique conventions/hooks/whatever. 
>  Without documentation, writers have to view many doc source code to attempt 
> to comprehend what those conventions are.  Similarly, these conventions 
> prevent standard reStructured text from rendering cleanly (for instance, 
> http://rst.ninjs.org/ shows tons of errors for any given doc file we have --  
> http://rst.ninjs.org/?n=aa8dc0bc3e337df7a2b5e14757debc81=basic).  
> Lastly, we should provide explicit, step by step instructions on how to get a 
> local version of sphinx up and running that a non developer can follow.  
> We need to document:
> - what are all the trafficserver specific hooks/conventions? 
> - when should they be used?
> - how they should be used?
> - how to preview a change without pushing to production?
> For instance, Igor noted as part of reviewing 
> https://issues.apache.org/jira/browse/TS-2183 :
> "General: all of the CAPSLOCK words should be put in the glossary"
> - how does one mark a term in the doc as having a glossary item?
> - where (what file) would the item's definition go?
> - what is the structure of that definition?
> Some other specific markup that needs explanation:
> :ts:cv:
> ts:const:
> ts:git:
> Similarly, it's also not clear to me when to choose markup like 
> `proxy.config.http.server_ports`_ versus :index: vs :ts:cv: vs :ref: etc.



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

[jira] [Created] (TS-4192) Coredump in HPACK encoding

[Bryan Call (JIRA)]

Bryan Call created TS-4192:
--

 Summary: Coredump in HPACK encoding
 Key: TS-4192
 URL: https://issues.apache.org/jira/browse/TS-4192
 Project: Traffic Server
  Issue Type: Bug
  Components: HTTP/2
Reporter: Bryan Call


{code}
#0  0x00972f44 in mime_hdr_field_detach (mh=0x61d002955508, 
field=0x629002954de8, detach_all_dups=) at MIME.cc:1582
name_length = 
prev = 0x0
first = 
next_dup = 
#1  0x00976daa in mime_hdr_field_delete (heap=0x61d002955480, 
mh=0x61d002955508, field=field@entry=0x629002954de8, 
delete_all_dups=delete_all_dups@entry=false) at MIME.cc:1631
No locals.
#2  0x00844c6d in field_delete (delete_all_dups=false, 
field=0x629002954de8, this=) at ../../proxy/hdrs/MIME.h:1169
No locals.
#3  Http2DynamicTable::add_header_field (this=0x607000fa8b60, field=) at HPACK.cc:307
last_field = 0x629002954de8
new_field = 0x629002954de8
name = 0x62809e18 "Via"
value = 0x625009705142 "http/1.0 c1.ycs.ne1.yahoo.com 
(ApacheTrafficServer [cRs f ]), https/1.1 l28.ycs.sjb.yahoo.com 
(ApacheTrafficServer [cRs f ])\r\nServer: ATS\r\nConnection: 
keep-alive\r\n\r\n", '\276' ...
header_size = 
#4  0x00845112 in add_header_field_to_dynamic_table (field=, this=) at HPACK.cc:253
No locals.
#5  encode_literal_header_field_with_indexed_name 
(buf_start=buf_start@entry=0x7fffedda2487 , 
buf_end=buf_end@entry=0x7fffedda6437 "", header=...,
index=, indexing_table=..., 
type=type@entry=HPACK_FIELD_INDEXED_LITERAL) at HPACK.cc:527
p = 0x7fffedda2487 
len = 
prefix = 0 '\000'
flag = 0 '\000'
value = 
__FUNCTION__ = "encode_literal_header_field_with_indexed_name"
#6  0x0080a8ca in http2_write_header_field 
(out=out@entry=0x7fffedda2487 , 
end=end@entry=0x7fffedda6437 "", header=..., indexing_table=...) at HTTP2.cc:509
field_type = HPACK_FIELD_INDEXED_LITERAL
name = 
#7  0x0080c616 in http2_write_header_fragment 
(in=in@entry=0x61634340, field_iter=..., out=out@entry=0x7fffedda2441 
"\354l\226\320z\276\224\020T\276R( \005\265",
out_len=out_len@entry=16374, indexing_table=..., cont=@0x7fffedda2300: 
false) at HTTP2.cc:592
name = 0x62809e18 "Via"
p = 0x7fffedda2487 
end = 0x7fffedda6437 ""
len = 
field = 0x61d0052550a8
#8  0x008272a0 in Http2ConnectionState::send_headers_frame 
(this=this@entry=0x61818ee8, fetch_sm=) at 
Http2ConnectionState.cc:1009
type = HTTP2_FRAME_TYPE_HEADERS
__FUNCTION__ = "send_headers_frame"
buf_len = 16375
payload_length = 
flags = 0 '\000'
stream = 0x60f3e890
resp_header = 0x61634340
#9  0x008388db in Http2ConnectionState::main_event_handler 
(this=0x61818ee8, event=-2, edata=) at 
Http2ConnectionState.cc:779
fetch_sm = 
__FUNCTION__ = "main_event_handler"
{code}



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

[jira] [Updated] (TS-4192) Coredump in HPACK encoding

[Bryan Call (JIRA)]

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

Bryan Call updated TS-4192:
---
Affects Version/s: 6.1.1

> Coredump in HPACK encoding
> --
>
> Key: TS-4192
> URL: https://issues.apache.org/jira/browse/TS-4192
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 6.1.1
>Reporter: Bryan Call
>
> {code}
> #0  0x00972f44 in mime_hdr_field_detach (mh=0x61d002955508, 
> field=0x629002954de8, detach_all_dups=) at MIME.cc:1582
> name_length = 
> prev = 0x0
> first = 
> next_dup = 
> #1  0x00976daa in mime_hdr_field_delete (heap=0x61d002955480, 
> mh=0x61d002955508, field=field@entry=0x629002954de8, 
> delete_all_dups=delete_all_dups@entry=false) at MIME.cc:1631
> No locals.
> #2  0x00844c6d in field_delete (delete_all_dups=false, 
> field=0x629002954de8, this=) at ../../proxy/hdrs/MIME.h:1169
> No locals.
> #3  Http2DynamicTable::add_header_field (this=0x607000fa8b60, 
> field=) at HPACK.cc:307
> last_field = 0x629002954de8
> new_field = 0x629002954de8
> name = 0x62809e18 "Via"
> value = 0x625009705142 "http/1.0 c1.ycs.ne1.yahoo.com 
> (ApacheTrafficServer [cRs f ]), https/1.1 l28.ycs.sjb.yahoo.com 
> (ApacheTrafficServer [cRs f ])\r\nServer: ATS\r\nConnection: 
> keep-alive\r\n\r\n", '\276' ...
> header_size = 
> #4  0x00845112 in add_header_field_to_dynamic_table (field= out>, this=) at HPACK.cc:253
> No locals.
> #5  encode_literal_header_field_with_indexed_name 
> (buf_start=buf_start@entry=0x7fffedda2487 , 
> buf_end=buf_end@entry=0x7fffedda6437 "", header=...,
> index=, indexing_table=..., 
> type=type@entry=HPACK_FIELD_INDEXED_LITERAL) at HPACK.cc:527
> p = 0x7fffedda2487 
> len = 
> prefix = 0 '\000'
> flag = 0 '\000'
> value = 
> __FUNCTION__ = "encode_literal_header_field_with_indexed_name"
> #6  0x0080a8ca in http2_write_header_field 
> (out=out@entry=0x7fffedda2487 , 
> end=end@entry=0x7fffedda6437 "", header=..., indexing_table=...) at 
> HTTP2.cc:509
> field_type = HPACK_FIELD_INDEXED_LITERAL
> name = 
> #7  0x0080c616 in http2_write_header_fragment 
> (in=in@entry=0x61634340, field_iter=..., out=out@entry=0x7fffedda2441 
> "\354l\226\320z\276\224\020T\276R( \005\265",
> out_len=out_len@entry=16374, indexing_table=..., cont=@0x7fffedda2300: 
> false) at HTTP2.cc:592
> name = 0x62809e18 "Via"
> p = 0x7fffedda2487 
> end = 0x7fffedda6437 ""
> len = 
> field = 0x61d0052550a8
> #8  0x008272a0 in Http2ConnectionState::send_headers_frame 
> (this=this@entry=0x61818ee8, fetch_sm=) at 
> Http2ConnectionState.cc:1009
> type = HTTP2_FRAME_TYPE_HEADERS
> __FUNCTION__ = "send_headers_frame"
> buf_len = 16375
> payload_length = 
> flags = 0 '\000'
> stream = 0x60f3e890
> resp_header = 0x61634340
> #9  0x008388db in Http2ConnectionState::main_event_handler 
> (this=0x61818ee8, event=-2, edata=) at 
> Http2ConnectionState.cc:779
> fetch_sm = 
> __FUNCTION__ = "main_event_handler"
> {code}



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

[jira] [Updated] (TS-4188) Client initial window size is set incorrectly in HTTP/2

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4188:
--
Fix Version/s: 6.1.2

> Client initial window size is set incorrectly in HTTP/2
> ---
>
> Key: TS-4188
> URL: https://issues.apache.org/jira/browse/TS-4188
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 6.1.1
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.1.2, 6.2.0
>
>
> The current initial window size for the client connection is being set to 
> 1MB.  The server MUST not override the default value of 64KB.



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

[jira] [Updated] (TS-4188) Client initial window size is set incorrectly in HTTP/2

[Leif Hedstrom (JIRA)]

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

Leif Hedstrom updated TS-4188:
--
Backport to Version:   (was: 6.1.2)

> Client initial window size is set incorrectly in HTTP/2
> ---
>
> Key: TS-4188
> URL: https://issues.apache.org/jira/browse/TS-4188
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 6.1.1
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.1.2, 6.2.0
>
>
> The current initial window size for the client connection is being set to 
> 1MB.  The server MUST not override the default value of 64KB.



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

[jira] [Commented] (TS-4188) Client initial window size is set incorrectly in HTTP/2

[ASF subversion and git services (JIRA)]

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

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

Commit 25ec8547d01ad93e413f62574d5080f1490526c4 in trafficserver's branch 
refs/heads/6.1.x from [~bcall]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=25ec854 ]

TS-4188: Client initial window size is set incorrectly in HTTP/2

This closes #462

(cherry picked from commit 8c38c6c42dd420b3cf54288fbbe25e98211218a9)


> Client initial window size is set incorrectly in HTTP/2
> ---
>
> Key: TS-4188
> URL: https://issues.apache.org/jira/browse/TS-4188
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 6.1.1
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.1.2, 6.2.0
>
>
> The current initial window size for the client connection is being set to 
> 1MB.  The server MUST not override the default value of 64KB.



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

[jira] [Commented] (TS-4188) Client initial window size is set incorrectly in HTTP/2

[ASF subversion and git services (JIRA)]

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

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

Commit 01eb69749bd3dcc85a4082657adc17afa270ffe2 in trafficserver's branch 
refs/heads/6.1.x from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=01eb697 ]

Updated CHANGES for TS-4188


> Client initial window size is set incorrectly in HTTP/2
> ---
>
> Key: TS-4188
> URL: https://issues.apache.org/jira/browse/TS-4188
> Project: Traffic Server
>  Issue Type: Bug
>  Components: HTTP/2
>Affects Versions: 6.1.1
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 6.1.2, 6.2.0
>
>
> The current initial window size for the client connection is being set to 
> 1MB.  The server MUST not override the default value of 64KB.



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