[jira] [Work logged] (TS-4990) Add support for new apis in ts_lua
[ https://issues.apache.org/jira/browse/TS-4990?focusedWorklogId=31362=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31362 ] ASF GitHub Bot logged work on TS-4990: -- Author: ASF GitHub Bot Created on: 01/Nov/16 04:12 Start Date: 01/Nov/16 04:12 Worklog Time Spent: 10m Work Description: Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/1127 FreeBSD build *successful*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/1129/ for details. Issue Time Tracking --- Worklog Id: (was: 31362) Time Spent: 1.5h (was: 1h 20m) > Add support for new apis in ts_lua > -- > > Key: TS-4990 > URL: https://issues.apache.org/jira/browse/TS-4990 > Project: Traffic Server > Issue Type: Improvement > Components: Lua, Plugins >Reporter: Kit Chan >Assignee: Kit Chan > Fix For: 7.1.0 > > Time Spent: 1.5h > Remaining Estimate: 0h > > Want to add support for the following apis in ts_lua plugin > TSHttpTxnParentProxyGet > TSHttpTxnParentProxySet > TSHttpTxnClientProtocolStackGet > TSHttpTxnServerPush > TSHttpTxnIsWebsocket > TSHttpTxnPluginTagGet > TSHttpTxnServerAddrSet -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #1127: [TS-4990] support new apis in ts_lua
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/1127 FreeBSD build *successful*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/1129/ for details. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Work logged] (TS-4990) Add support for new apis in ts_lua
[ https://issues.apache.org/jira/browse/TS-4990?focusedWorklogId=31361=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31361 ] ASF GitHub Bot logged work on TS-4990: -- Author: ASF GitHub Bot Created on: 01/Nov/16 04:04 Start Date: 01/Nov/16 04:04 Worklog Time Spent: 10m Work Description: Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/1127 Linux build *failed*! See https://ci.trafficserver.apache.org/job/Github-Linux/1023/ for details. Issue Time Tracking --- Worklog Id: (was: 31361) Time Spent: 1h 20m (was: 1h 10m) > Add support for new apis in ts_lua > -- > > Key: TS-4990 > URL: https://issues.apache.org/jira/browse/TS-4990 > Project: Traffic Server > Issue Type: Improvement > Components: Lua, Plugins >Reporter: Kit Chan >Assignee: Kit Chan > Fix For: 7.1.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > Want to add support for the following apis in ts_lua plugin > TSHttpTxnParentProxyGet > TSHttpTxnParentProxySet > TSHttpTxnClientProtocolStackGet > TSHttpTxnServerPush > TSHttpTxnIsWebsocket > TSHttpTxnPluginTagGet > TSHttpTxnServerAddrSet -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #1127: [TS-4990] support new apis in ts_lua
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/1127 Linux build *failed*! See https://ci.trafficserver.apache.org/job/Github-Linux/1023/ for details. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1158: TS-5015: Convert storage configuration file to Lu...
Github user shukitchan commented on the issue: https://github.com/apache/trafficserver/pull/1158 After the summit, here are the things I learn I should do 1) Add a flag to allow backward compatibility. 2) combine volume.config and hosting.config as well in this new lua format. 3) Some clean up and resolve conflicts 4) squash before commit, of course And then we should have a separate JIRA to remove the legacy code and make this change mandatory for 8.0.0 @jpeach any other comments you have? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Work logged] (TS-5015) Convert storage config file to Lua
[ https://issues.apache.org/jira/browse/TS-5015?focusedWorklogId=31360=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31360 ] ASF GitHub Bot logged work on TS-5015: -- Author: ASF GitHub Bot Created on: 01/Nov/16 04:04 Start Date: 01/Nov/16 04:04 Worklog Time Spent: 10m Work Description: Github user shukitchan commented on the issue: https://github.com/apache/trafficserver/pull/1158 After the summit, here are the things I learn I should do 1) Add a flag to allow backward compatibility. 2) combine volume.config and hosting.config as well in this new lua format. 3) Some clean up and resolve conflicts 4) squash before commit, of course And then we should have a separate JIRA to remove the legacy code and make this change mandatory for 8.0.0 @jpeach any other comments you have? Issue Time Tracking --- Worklog Id: (was: 31360) Time Spent: 1h 40m (was: 1.5h) > Convert storage config file to Lua > -- > > Key: TS-5015 > URL: https://issues.apache.org/jira/browse/TS-5015 > Project: Traffic Server > Issue Type: Improvement > Components: Cache, Lua >Reporter: Kit Chan >Assignee: Kit Chan > Fix For: 7.1.0 > > Time Spent: 1h 40m > Remaining Estimate: 0h > > Similar to TS-4548 > storage.config is the next good candidate to convert to Lua bindings. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-4990) Add support for new apis in ts_lua
[ https://issues.apache.org/jira/browse/TS-4990?focusedWorklogId=31359=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31359 ] ASF GitHub Bot logged work on TS-4990: -- Author: ASF GitHub Bot Created on: 01/Nov/16 03:59 Start Date: 01/Nov/16 03:59 Worklog Time Spent: 10m Work Description: Github user shukitchan commented on the issue: https://github.com/apache/trafficserver/pull/1127 @jpeach, I have updated the PR according to the comments. Please take a look. Issue Time Tracking --- Worklog Id: (was: 31359) Time Spent: 1h 10m (was: 1h) > Add support for new apis in ts_lua > -- > > Key: TS-4990 > URL: https://issues.apache.org/jira/browse/TS-4990 > Project: Traffic Server > Issue Type: Improvement > Components: Lua, Plugins >Reporter: Kit Chan >Assignee: Kit Chan > Fix For: 7.1.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > Want to add support for the following apis in ts_lua plugin > TSHttpTxnParentProxyGet > TSHttpTxnParentProxySet > TSHttpTxnClientProtocolStackGet > TSHttpTxnServerPush > TSHttpTxnIsWebsocket > TSHttpTxnPluginTagGet > TSHttpTxnServerAddrSet -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #1127: [TS-4990] support new apis in ts_lua
Github user shukitchan commented on the issue: https://github.com/apache/trafficserver/pull/1127 @jpeach, I have updated the PR according to the comments. Please take a look. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Work logged] (TS-4399) Management API breaks diagnostic log rotation
[
https://issues.apache.org/jira/browse/TS-4399?focusedWorklogId=31354=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31354
]
ASF GitHub Bot logged work on TS-4399:
--
Author: ASF GitHub Bot
Created on: 01/Nov/16 03:26
Start Date: 01/Nov/16 03:26
Worklog Time Spent: 10m
Work Description: Github user jpeach commented on a diff in the pull
request:
https://github.com/apache/trafficserver/pull/1073#discussion_r85870674
--- Diff: mgmt/LocalManager.cc ---
@@ -902,8 +907,13 @@ LocalManager::startProxy()
Vec real_proxy_options;
real_proxy_options.append(proxy_options, strlen(proxy_options));
+if (onetime_options && *onetime_options) {
+ real_proxy_options.append(" ", strlen(" "));
+ real_proxy_options.append(onetime_options, strlen(onetime_options));
+}
-if (!strstr(proxy_options, MGMT_OPT)) { // Make sure we're starting
the proxy in mgmt mode
+// Make sure we're starting the proxy in mgmt mode
+if (!strstr(proxy_options, MGMT_OPT) && !strstr(onetime_options,
MGMT_OPT)) {
--- End diff --
Prefer ``strstr(...) == 0``. It's just that little bit more readable.
Issue Time Tracking
---
Worklog Id: (was: 31354)
Time Spent: 2h (was: 1h 50m)
> Management API breaks diagnostic log rotation
> -
>
> Key: TS-4399
> URL: https://issues.apache.org/jira/browse/TS-4399
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, Management API
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Start up Traffic Server:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.02 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26952 26951 0 10:13AM ?? 0:00.08 /opt/ats/bin/traffic_server
> -M --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out --httpport 8080:fd=12
> {code}
> Now restart it using {{traffic_line -S}} followed by {{traffic_line -U}}:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.05 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26967 26951 0 10:13AM ?? 0:00.12 /opt/ats/bin/traffic_server
> -M --httpport 8080:fd=20
> {code}
> Note that we lost the {{\--bind_stdout}} and {{\--bind_stderr}} options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work logged] (TS-4399) Management API breaks diagnostic log rotation
[
https://issues.apache.org/jira/browse/TS-4399?focusedWorklogId=31355=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31355
]
ASF GitHub Bot logged work on TS-4399:
--
Author: ASF GitHub Bot
Created on: 01/Nov/16 03:26
Start Date: 01/Nov/16 03:26
Worklog Time Spent: 10m
Work Description: Github user jpeach commented on a diff in the pull
request:
https://github.com/apache/trafficserver/pull/1073#discussion_r85870603
--- Diff: mgmt/api/CoreAPI.cc ---
@@ -184,21 +184,19 @@ ProxyStateSet(TSProxyStateT state, TSCacheClearT
clear)
ink_strlcat(tsArgs, " -k", sizeof(tsArgs));
}
-if (strlen(tsArgs) > 0) { /* Passed command line args for proxy */
- ats_free(lmgmt->proxy_options);
- lmgmt->proxy_options = ats_strdup(tsArgs);
- mgmt_log("[ProxyStateSet] Traffic Server Args: '%s'\n",
lmgmt->proxy_options);
-}
+mgmt_log("[ProxyStateSet] Traffic Server Args: '%s %s'\n",
lmgmt->proxy_options ? lmgmt->proxy_options : "", tsArgs);
lmgmt->run_proxy = true;
lmgmt->listenForProxy();
+lmgmt->startProxy(tsArgs);
--- End diff --
Do you actually need to do the sleeping stuff here? Since you now call
``LocalManager:: startProxy()`` directly, you have the return value to know
that it succeeded. I don't think that the contract for this API needs to
include waiting for a message.
```C
return lmgmt->startProxy(tsArgs) ? TS_ERR_OKAY : TS_ERR_FAIL;
```
Issue Time Tracking
---
Worklog Id: (was: 31355)
Time Spent: 2h (was: 1h 50m)
> Management API breaks diagnostic log rotation
> -
>
> Key: TS-4399
> URL: https://issues.apache.org/jira/browse/TS-4399
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, Management API
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Start up Traffic Server:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.02 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26952 26951 0 10:13AM ?? 0:00.08 /opt/ats/bin/traffic_server
> -M --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out --httpport 8080:fd=12
> {code}
> Now restart it using {{traffic_line -S}} followed by {{traffic_line -U}}:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.05 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26967 26951 0 10:13AM ?? 0:00.12 /opt/ats/bin/traffic_server
> -M --httpport 8080:fd=20
> {code}
> Note that we lost the {{\--bind_stdout}} and {{\--bind_stderr}} options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver pull request #1073: TS-4399 TS-4400 Management API messes up p...
Github user jpeach commented on a diff in the pull request: https://github.com/apache/trafficserver/pull/1073#discussion_r85870712 --- Diff: mgmt/LocalManager.cc --- @@ -189,6 +189,7 @@ LocalManager::LocalManager(bool proxy_on) : BaseManager(), run_proxy(proxy_on), proxy_launch_outstanding = false; mgmt_shutdown_outstanding = MGMT_PENDING_NONE; proxy_running = 0; + coreapi_sleep = true; --- End diff -- As mentioned in the other comment, I think we can get away without this. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver pull request #1073: TS-4399 TS-4400 Management API messes up p...
Github user jpeach commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/1073#discussion_r85870674
--- Diff: mgmt/LocalManager.cc ---
@@ -902,8 +907,13 @@ LocalManager::startProxy()
Vec real_proxy_options;
real_proxy_options.append(proxy_options, strlen(proxy_options));
+if (onetime_options && *onetime_options) {
+ real_proxy_options.append(" ", strlen(" "));
+ real_proxy_options.append(onetime_options, strlen(onetime_options));
+}
-if (!strstr(proxy_options, MGMT_OPT)) { // Make sure we're starting
the proxy in mgmt mode
+// Make sure we're starting the proxy in mgmt mode
+if (!strstr(proxy_options, MGMT_OPT) && !strstr(onetime_options,
MGMT_OPT)) {
--- End diff --
Prefer ``strstr(...) == 0``. It's just that little bit more readable.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[GitHub] trafficserver pull request #1073: TS-4399 TS-4400 Management API messes up p...
Github user jpeach commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/1073#discussion_r85870603
--- Diff: mgmt/api/CoreAPI.cc ---
@@ -184,21 +184,19 @@ ProxyStateSet(TSProxyStateT state, TSCacheClearT
clear)
ink_strlcat(tsArgs, " -k", sizeof(tsArgs));
}
-if (strlen(tsArgs) > 0) { /* Passed command line args for proxy */
- ats_free(lmgmt->proxy_options);
- lmgmt->proxy_options = ats_strdup(tsArgs);
- mgmt_log("[ProxyStateSet] Traffic Server Args: '%s'\n",
lmgmt->proxy_options);
-}
+mgmt_log("[ProxyStateSet] Traffic Server Args: '%s %s'\n",
lmgmt->proxy_options ? lmgmt->proxy_options : "", tsArgs);
lmgmt->run_proxy = true;
lmgmt->listenForProxy();
+lmgmt->startProxy(tsArgs);
--- End diff --
Do you actually need to do the sleeping stuff here? Since you now call
``LocalManager:: startProxy()`` directly, you have the return value to know
that it succeeded. I don't think that the contract for this API needs to
include waiting for a message.
```C
return lmgmt->startProxy(tsArgs) ? TS_ERR_OKAY : TS_ERR_FAIL;
```
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Updated] (TS-5024) Gzip plugin gzips multiple times
[ https://issues.apache.org/jira/browse/TS-5024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Meera Mosale Nataraja updated TS-5024: -- Description: Gzip plugin gzips multiple times when you enable redirection by following settings or using escalate plugin. Enable redirection: CONFIG proxy.config.http.redirection_enabled INT 1 CONFIG proxy.config.http.number_of_redirections INT 3 Curl command output is provided below. Notice multiple "Content-Encoding: gzip" headers. curl -v -o/dev/null http://proxy-test:8080/get -H "Host: proxy-test" -x localhost:8080 -H "Accept-encoding: gzip" * About to connect() to proxy localhost port 8080 (#0) * Trying ::1... connected * Connected to localhost (::1) port 8080 (#0) > GET http://proxy-test:8080/get HTTP/1.1 > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.21 > Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > Accept: */* > Proxy-Connection: Keep-Alive > Host: proxy-test > Accept-encoding: gzip > % Total% Received % Xferd Average Speed TimeTime Time Current Dload Upload Total SpentLeft Speed 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- 0< HTTP/1.1 404 Not Found < Server: ATS/7.1.0 < X-Frame-Options: SAMEORIGIN < X-Xss-Protection: 1; mode=block < Accept-Ranges: bytes < X-Content-Type-Options: nosniff < Content-Type: text/html; charset=UTF-8 < Cache-Control: max-age=300 < Expires: Mon, 31 Oct 2016 18:29:44 GMT < Date: Mon, 31 Oct 2016 18:24:44 GMT < Content-Encoding: gzip < Vary: Accept-Encoding < Content-Encoding: gzip < Content-Encoding: gzip < Content-Length: 4456 < Age: 0 < Proxy-Connection: keep-alive > Gzip plugin gzips multiple times > > > Key: TS-5024 > URL: https://issues.apache.org/jira/browse/TS-5024 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Meera Mosale Nataraja >Assignee: Meera Mosale Nataraja > > Gzip plugin gzips multiple times when you enable redirection by following > settings or using escalate plugin. > Enable redirection: > CONFIG proxy.config.http.redirection_enabled INT 1 > CONFIG proxy.config.http.number_of_redirections INT 3 > Curl command output is provided below. Notice multiple "Content-Encoding: > gzip" headers. > curl -v -o/dev/null http://proxy-test:8080/get -H "Host: proxy-test" -x > localhost:8080 -H "Accept-encoding: gzip" > * About to connect() to proxy localhost port 8080 (#0) > * Trying ::1... connected > * Connected to localhost (::1) port 8080 (#0) > > GET http://proxy-test:8080/get HTTP/1.1 > > User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.21 > > Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2 > > Accept: */* > > Proxy-Connection: Keep-Alive > > Host: proxy-test > > Accept-encoding: gzip > > > % Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft Speed > 0 00 00 0 0 0 --:--:-- --:--:-- --:--:-- > 0< HTTP/1.1 404 Not Found > < Server: ATS/7.1.0 > < X-Frame-Options: SAMEORIGIN > < X-Xss-Protection: 1; mode=block > < Accept-Ranges: bytes > < X-Content-Type-Options: nosniff > < Content-Type: text/html; charset=UTF-8 > < Cache-Control: max-age=300 > < Expires: Mon, 31 Oct 2016 18:29:44 GMT > < Date: Mon, 31 Oct 2016 18:24:44 GMT > < Content-Encoding: gzip > < Vary: Accept-Encoding > < Content-Encoding: gzip > < Content-Encoding: gzip > < Content-Length: 4456 > < Age: 0 > < Proxy-Connection: keep-alive -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5024) Gzip plugin gzips multiple times
[ https://issues.apache.org/jira/browse/TS-5024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Meera Mosale Nataraja updated TS-5024: -- Summary: Gzip plugin gzips multiple times (was: Gzip plugin ) > Gzip plugin gzips multiple times > > > Key: TS-5024 > URL: https://issues.apache.org/jira/browse/TS-5024 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Meera Mosale Nataraja >Assignee: Meera Mosale Nataraja > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5024) Gzip plugin
[ https://issues.apache.org/jira/browse/TS-5024?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Meera Mosale Nataraja updated TS-5024: -- Assignee: Meera Mosale Nataraja Component/s: Plugins > Gzip plugin > > > Key: TS-5024 > URL: https://issues.apache.org/jira/browse/TS-5024 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Meera Mosale Nataraja >Assignee: Meera Mosale Nataraja > -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-5024) Gzip plugin
Meera Mosale Nataraja created TS-5024: - Summary: Gzip plugin Key: TS-5024 URL: https://issues.apache.org/jira/browse/TS-5024 Project: Traffic Server Issue Type: Bug Reporter: Meera Mosale Nataraja -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-5023) Allow diags.log and traffic.out to be rotated by size or time
[ https://issues.apache.org/jira/browse/TS-5023?focusedWorklogId=31351=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31351 ] ASF GitHub Bot logged work on TS-5023: -- Author: ASF GitHub Bot Created on: 31/Oct/16 20:28 Start Date: 31/Oct/16 20:28 Worklog Time Spent: 10m Work Description: GitHub user danobi opened a pull request: https://github.com/apache/trafficserver/pull/1165 TS-5023 Allow diags.log and traffic.out to be rotated by size or time Create a third option for diagnostic logs: roll by time or size, whichever comes first. This is useful in certain circumstances. You can merge this pull request into a Git repository by running: $ git pull https://github.com/danobi/trafficserver TS-5023 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1165.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 #1165 Issue Time Tracking --- Worklog Id: (was: 31351) Time Spent: 10m Remaining Estimate: 0h > Allow diags.log and traffic.out to be rotated by size or time > - > > Key: TS-5023 > URL: https://issues.apache.org/jira/browse/TS-5023 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Daniel Xu >Assignee: Daniel Xu > Fix For: 7.1.0 > > Time Spent: 10m > Remaining Estimate: 0h > > Create a 3rd option for diags.log and traffic.out to be rolled by time OR > size. Currently access logs have this feature and diagnostic logs don't. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver pull request #1165: TS-5023 Allow diags.log and traffic.out to...
GitHub user danobi opened a pull request: https://github.com/apache/trafficserver/pull/1165 TS-5023 Allow diags.log and traffic.out to be rotated by size or time Create a third option for diagnostic logs: roll by time or size, whichever comes first. This is useful in certain circumstances. You can merge this pull request into a Git repository by running: $ git pull https://github.com/danobi/trafficserver TS-5023 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1165.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 #1165 --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Work logged] (TS-4978) CID 1364311: Memory - illegal accesses (USE_AFTER_FREE) in iocore/net/SSLConfig.cc
[
https://issues.apache.org/jira/browse/TS-4978?focusedWorklogId=31350=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31350
]
ASF GitHub Bot logged work on TS-4978:
--
Author: ASF GitHub Bot
Created on: 31/Oct/16 20:15
Start Date: 31/Oct/16 20:15
Worklog Time Spent: 10m
Work Description: Github user persiaAziz commented on the issue:
https://github.com/apache/trafficserver/pull/1120
The conflict is resolved. Please check
Issue Time Tracking
---
Worklog Id: (was: 31350)
Time Spent: 1h 20m (was: 1h 10m)
> CID 1364311: Memory - illegal accesses (USE_AFTER_FREE) in
> iocore/net/SSLConfig.cc
>
>
> Key: TS-4978
> URL: https://issues.apache.org/jira/browse/TS-4978
> Project: Traffic Server
> Issue Type: Bug
> Components: TLS
>Reporter: Leif Hedstrom
>Assignee: Syeda Persia Aziz
> Fix For: 7.1.0
>
> Time Spent: 1h 20m
> Remaining Estimate: 0h
>
> I think this is perhaps from TS-4858:
> {code}
> *** CID 1364311: Memory - illegal accesses (USE_AFTER_FREE)
> /iocore/net/SSLConfig.cc: 258 in SSLConfigParams::initialize()()
> 252 ats_free(ssl_server_ca_cert_filename);
> 253 ats_free(CACertRelativePath);
> 254
> 255 #if HAVE_OPENSSL_SESSION_TICKETS
> 256 REC_ReadConfigStringAlloc(ticket_key_filename,
> "proxy.config.ssl.server.ticket_key.filename");
> 257 if (this->ticket_key_filename != NULL) {
>CID 1364311: Memory - illegal accesses (USE_AFTER_FREE)
>Passing freed pointer "this->ticket_key_filename" as an argument to
> "relative_to".
> 258 ats_scoped_str
> ticket_key_path(Layout::relative_to(this->serverCertPathOnly,
> this->ticket_key_filename));
> 259 default_global_keyblock =
> ssl_create_ticket_keyblock(ticket_key_path);
> 260 } else {
> 261 default_global_keyblock = ssl_create_ticket_keyblock(NULL);
> 262 }
> 263 #endif
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver issue #1120: TS-4978: illegal memory access with ticket_key.fi...
Github user persiaAziz commented on the issue: https://github.com/apache/trafficserver/pull/1120 The conflict is resolved. Please check --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Work logged] (TS-4834) Expose bad disk and disk access failures
[
https://issues.apache.org/jira/browse/TS-4834?focusedWorklogId=31349=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31349
]
ASF GitHub Bot logged work on TS-4834:
--
Author: ASF GitHub Bot
Created on: 31/Oct/16 18:16
Start Date: 31/Oct/16 18:16
Worklog Time Spent: 10m
Work Description: Github user gtenev commented on the issue:
https://github.com/apache/trafficserver/pull/996
@zwoop, it is ready to land now.
Issue Time Tracking
---
Worklog Id: (was: 31349)
Time Spent: 3h 40m (was: 3.5h)
> Expose bad disk and disk access failures
>
>
> Key: TS-4834
> URL: https://issues.apache.org/jira/browse/TS-4834
> Project: Traffic Server
> Issue Type: Improvement
> Components: Cache, Metrics
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
> Fix For: 7.1.0
>
> Time Spent: 3h 40m
> Remaining Estimate: 0h
>
> We would like to monitor low-level disk access failures and disks marked by
> ATS as bad.
> I have a patch that exposes that information through
> {code}
> proxy.process.cache.disk_error_count 10
> proxy.process.cache.disk_bad_count 5
> {code}
> and the following tests/shows how it would work...
> Start ATS with 2 disks and tail {{diags.log}}
> {code}
> $ cat etc/trafficserver/storage.config
> /dev/sdb
> /dev/sdc
> $ tail -f var/log/trafficserver/diags.log
> [Sep 8 12:18:48.149] Server {0x2b5f43db54c0} NOTE: traffic server running
> [Sep 8 12:18:48.198] Server {0x2b5f44654700} NOTE: cache enabled
> {code}
> Check related metrics and observe all 0s
> {code}
> $ ./bin/traffic_ctl metric match "proxy.process.cache*.disk.*"
> "proxy.process.cache.*(read|write).failure"
> "proxy.process.http.cache_(read|write)_errors"
> proxy.process.cache.disk_error_count 0
> proxy.process.cache.disk_bad_count 0
> proxy.process.cache.read.failure 0
> proxy.process.cache.write.failure 0
> proxy.process.cache.volume_0.read.failure 0
> proxy.process.cache.volume_0.write.failure 0
> proxy.process.http.cache_write_errors 0
> proxy.process.http.cache_read_errors 0
> {code}
> Now using your favorite hard disk failure injection tool inject 10 failures,
> by setting both disks used by this setup {{/dev/sdb}} and {{/dev/sdc}} to
> fail all reads. And shoot 5 requests causing 10 failed reads.
> {code}
> $ for i in 1 2 3 4 5; do curl -x 127.0.0.1:80 http://example.com/1 -o
> /dev/null -s; done
> $ tail -f var/log/trafficserver/diags.log
> [Sep 8 12:19:09.758] Server {0x2aaab4302700} WARNING: cache disk operation
> failed READ -1 0
> [Sep 8 12:19:09.759] Server {0x2aaac0100700} WARNING: cache disk operation
> failed READ -1 0
> [Sep 8 12:19:09.764] Server {0x2b5f43db54c0} WARNING: Error accessing Disk
> /dev/sdb [1/10]
> [Sep 8 12:19:09.769] Server {0x2b5f44654700} WARNING: Error accessing Disk
> /dev/sdb [2/10]
> [Sep 8 12:19:09.785] Server {0x2aaac0100700} WARNING: cache disk operation
> failed READ -1 0
> [Sep 8 12:19:09.786] Server {0x2aaab4302700} WARNING: cache disk operation
> failed READ -1 0
> [Sep 8 12:19:09.791] Server {0x2b5f44654700} WARNING: Error accessing Disk
> /dev/sdb [3/10]
> [Sep 8 12:19:09.796] Server {0x2b5f43db54c0} WARNING: Error accessing Disk
> /dev/sdb [4/10]
> [Sep 8 12:19:09.812] Server {0x2aaab4100700} WARNING: cache disk operation
> failed READ -1 0
> [Sep 8 12:19:09.813] Server {0x2aaacc100700} WARNING: cache disk operation
> failed READ -1 0
> [Sep 8 12:19:09.817] Server {0x2b5f43db54c0} WARNING: Error accessing Disk
> /dev/sdb [5/10]
> [Sep 8 12:19:09.823] Server {0x2b5f44654700} WARNING: Error accessing Disk
> /dev/sdb [6/10]
> [Sep 8 12:19:09.843] Server {0x2aaacc302700} WARNING: cache disk operation
> failed READ -1 0
> [Sep 8 12:19:09.844] Server {0x2aaad8100700} WARNING: cache disk operation
> failed READ -1 0
> [Sep 8 12:19:09.847] Server {0x2b5f44654700} WARNING: Error accessing Disk
> /dev/sdb [7/10]
> [Sep 8 12:19:09.854] Server {0x2b5f43db54c0} WARNING: Error accessing Disk
> /dev/sdb [8/10]
> [Sep 8 12:19:09.874] Server {0x2aaacc302700} WARNING: cache disk operation
> failed READ -1 0
> [Sep 8 12:19:09.875] Server {0x2aaad8100700} WARNING: cache disk operation
> failed READ -1 0
> [Sep 8 12:19:09.880] Server {0x2b5f43db54c0} WARNING: Error accessing Disk
> /dev/sdb [9/10]
> [Sep 8 12:19:09.887] Server {0x2b5f44654700} WARNING: too many errors
> accessing disk /dev/sdb [10/10]: declaring disk bad
> {code}
> We see 5 read failures which triggered 10 actually disk reads and marked the
> failing disk as a bad disk.
> {code}
> $ ./bin/traffic_ctl metric match "proxy.process.cache*.disk.*"
> "proxy.process.cache.*(read|write).failure"
> "proxy.process.http.cache_(read|write)_errors"
> proxy.process.cache.disk_error_count 10
>
[GitHub] trafficserver issue #996: TS-4834 Expose bad disk and disk access failures
Github user gtenev commented on the issue: https://github.com/apache/trafficserver/pull/996 @zwoop, it is ready to land now. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Resolved] (TS-5013) Master does not build on omnios
[ https://issues.apache.org/jira/browse/TS-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call resolved TS-5013. Resolution: Fixed > Master does not build on omnios > --- > > Key: TS-5013 > URL: https://issues.apache.org/jira/browse/TS-5013 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Theo Schlossnagle >Assignee: Theo Schlossnagle > Fix For: 7.1.0 > > Time Spent: 40m > Remaining Estimate: 0h > > termios defines are used without a header and the websockets example code > doesn't have a be64toh define for the OmniOS platform. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5013) Master does not build on omnios
[ https://issues.apache.org/jira/browse/TS-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5013: --- Assignee: Theo Schlossnagle > Master does not build on omnios > --- > > Key: TS-5013 > URL: https://issues.apache.org/jira/browse/TS-5013 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Theo Schlossnagle >Assignee: Theo Schlossnagle > Fix For: 7.1.0 > > Time Spent: 40m > Remaining Estimate: 0h > > termios defines are used without a header and the websockets example code > doesn't have a be64toh define for the OmniOS platform. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5013) Master does not build on omnios
[ https://issues.apache.org/jira/browse/TS-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5013: --- Component/s: Build > Master does not build on omnios > --- > > Key: TS-5013 > URL: https://issues.apache.org/jira/browse/TS-5013 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Theo Schlossnagle >Assignee: Theo Schlossnagle > Fix For: 7.1.0 > > Time Spent: 40m > Remaining Estimate: 0h > > termios defines are used without a header and the websockets example code > doesn't have a be64toh define for the OmniOS platform. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-5004) CID 1021675 Structurally dead code
[ https://issues.apache.org/jira/browse/TS-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call resolved TS-5004. Resolution: Fixed > CID 1021675 Structurally dead code > -- > > Key: TS-5004 > URL: https://issues.apache.org/jira/browse/TS-5004 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Nathan Garabedian >Assignee: Nathan Garabedian > Fix For: 7.1.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Some lines of code exist after a return 1; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5016) TS should allow force reload, and may also check inclued files
[ https://issues.apache.org/jira/browse/TS-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5016: --- Component/s: Configuration > TS should allow force reload, and may also check inclued files > --- > > Key: TS-5016 > URL: https://issues.apache.org/jira/browse/TS-5016 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: James Fang > Fix For: 7.1.0 > > > 1) on config change, if TS hasn't detect the changes yet - traffic_ctl config > status show "current", > reload seems skipped. so user may need to wait for the detection. > this happens if config file are generated by programs since the reload > is immediately. > 2) for included config files, such as .include from remap.config, > if included files changes, TS still seems configuration as current -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5002) No core files created at crash
[ https://issues.apache.org/jira/browse/TS-5002?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5002: --- Fix Version/s: 7.1.0 > No core files created at crash > -- > > Key: TS-5002 > URL: https://issues.apache.org/jira/browse/TS-5002 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Roee Gil > Fix For: 7.1.0 > > > When trying to enable core dump creation on ATS 5.3.2 the crash log is > written to traffic.out, but no matter what change is done in record.config, > or in the sysctl the core file it self is not created. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5004) CID 1021675 Structurally dead code
[ https://issues.apache.org/jira/browse/TS-5004?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5004: --- Fix Version/s: 7.1.0 > CID 1021675 Structurally dead code > -- > > Key: TS-5004 > URL: https://issues.apache.org/jira/browse/TS-5004 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Reporter: Nathan Garabedian >Assignee: Nathan Garabedian > Fix For: 7.1.0 > > Time Spent: 20m > Remaining Estimate: 0h > > Some lines of code exist after a return 1; -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5017) ip_allow.config seems use the first matched rule
[ https://issues.apache.org/jira/browse/TS-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5017: --- Fix Version/s: sometime > ip_allow.config seems use the first matched rule > > > Key: TS-5017 > URL: https://issues.apache.org/jira/browse/TS-5017 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: James Fang > Fix For: sometime > > > as title, rules are not merged, and the first matched rule take effect. > shall we update the doc for this ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5017) ip_allow.config seems use the first matched rule
[ https://issues.apache.org/jira/browse/TS-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5017: --- Fix Version/s: (was: sometime) Docs > ip_allow.config seems use the first matched rule > > > Key: TS-5017 > URL: https://issues.apache.org/jira/browse/TS-5017 > Project: Traffic Server > Issue Type: Improvement > Components: Documentation >Reporter: James Fang > Fix For: Docs > > > as title, rules are not merged, and the first matched rule take effect. > shall we update the doc for this ? -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5013) Master does not build on omnios
[ https://issues.apache.org/jira/browse/TS-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5013: --- Fix Version/s: 7.1.0 > Master does not build on omnios > --- > > Key: TS-5013 > URL: https://issues.apache.org/jira/browse/TS-5013 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Theo Schlossnagle >Assignee: Theo Schlossnagle > Fix For: 7.1.0 > > Time Spent: 40m > Remaining Estimate: 0h > > termios defines are used without a header and the websockets example code > doesn't have a be64toh define for the OmniOS platform. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5014) If ip_allow.config is missing all access is blocked
[
https://issues.apache.org/jira/browse/TS-5014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-5014:
---
Component/s: Security
> If ip_allow.config is missing all access is blocked
> ---
>
> Key: TS-5014
> URL: https://issues.apache.org/jira/browse/TS-5014
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Security
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>
> An empty {{ip_allow.config}} should block all traffic (default deny) but if
> the file does not exist it should disable IP allow (default allow). Currently
> if the file does not exist it acts as an empty file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5014) If ip_allow.config is missing all access is blocked
[
https://issues.apache.org/jira/browse/TS-5014?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-5014:
---
Fix Version/s: 7.1.0
> If ip_allow.config is missing all access is blocked
> ---
>
> Key: TS-5014
> URL: https://issues.apache.org/jira/browse/TS-5014
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Security
>Reporter: Alan M. Carroll
>Assignee: Alan M. Carroll
> Fix For: 7.1.0
>
>
> An empty {{ip_allow.config}} should block all traffic (default deny) but if
> the file does not exist it should disable IP allow (default allow). Currently
> if the file does not exist it acts as an empty file.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5016) TS should allow force reload, and may also check inclued files
[ https://issues.apache.org/jira/browse/TS-5016?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5016: --- Fix Version/s: 7.1.0 > TS should allow force reload, and may also check inclued files > --- > > Key: TS-5016 > URL: https://issues.apache.org/jira/browse/TS-5016 > Project: Traffic Server > Issue Type: Improvement > Components: Configuration >Reporter: James Fang > Fix For: 7.1.0 > > > 1) on config change, if TS hasn't detect the changes yet - traffic_ctl config > status show "current", > reload seems skipped. so user may need to wait for the detection. > this happens if config file are generated by programs since the reload > is immediately. > 2) for included config files, such as .include from remap.config, > if included files changes, TS still seems configuration as current -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5023) Allow diags.log and traffic.out to be rotated by size or time
[ https://issues.apache.org/jira/browse/TS-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5023: --- Fix Version/s: 7.1.0 > Allow diags.log and traffic.out to be rotated by size or time > - > > Key: TS-5023 > URL: https://issues.apache.org/jira/browse/TS-5023 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Daniel Xu >Assignee: Daniel Xu > Fix For: 7.1.0 > > > Create a 3rd option for diags.log and traffic.out to be rolled by time OR > size. Currently access logs have this feature and diagnostic logs don't. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-5013) Master does not build on omnios
[ https://issues.apache.org/jira/browse/TS-5013?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5013: --- Summary: Master does not build on omnios (was: master does not build on omnios) > Master does not build on omnios > --- > > Key: TS-5013 > URL: https://issues.apache.org/jira/browse/TS-5013 > Project: Traffic Server > Issue Type: Bug > Components: Build >Reporter: Theo Schlossnagle > Fix For: 7.1.0 > > Time Spent: 40m > Remaining Estimate: 0h > > termios defines are used without a header and the websockets example code > doesn't have a be64toh define for the OmniOS platform. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4986) Memory leak in test_Map
[
https://issues.apache.org/jira/browse/TS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call reassigned TS-4986:
--
Assignee: Bryan Call
> Memory leak in test_Map
> ---
>
> Key: TS-4986
> URL: https://issues.apache.org/jira/browse/TS-4986
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Tests
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.1.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
> =
> ==22202==ERROR: LeakSanitizer: detected memory leaks
> Direct leak of 3216 byte(s) in 134 object(s) allocated from:
> #0 0x7f4d3de22ea0 in operator new(unsigned long)
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x402df9 in test_TSHashTable()
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:76
> #2 0x402380 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:214
> #3 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 112 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x406576 in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x406576 in Vec 2>::set_expand() ../../lib/ts/Vec.h:781
> #4 0x406576 in HashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:552
> #5 0x401d90 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:174
> #6 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in ChainHashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:691
> #6 0x401f26 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:196
> #7 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de22ea0 in operator new(unsigned long)
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x402d4a in test_TSHashTable()
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:73
> #2 0x402380 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:214
> #3 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in ChainHashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:691
> #6 0x401efe in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:194
> #7 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in ChainHashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:691
> #6 0x401f12 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:195
> #7 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf
[jira] [Updated] (TS-5022) Multiple Client Certificate to Origin
[ https://issues.apache.org/jira/browse/TS-5022?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Bryan Call updated TS-5022: --- Fix Version/s: 7.1.0 > Multiple Client Certificate to Origin > - > > Key: TS-5022 > URL: https://issues.apache.org/jira/browse/TS-5022 > Project: Traffic Server > Issue Type: Improvement > Components: Security, SSL, TLS >Reporter: Scott Beardsley >Assignee: Leif Hedstrom > Labels: yahoo > Fix For: 7.1.0 > > > Yahoo has a use case where the origin is doing mutual TLS authentication > which requires ATS to send a client certificate. This works fine (for now) > because ATS supports configuring *one* client cert but this feature should > really allow multiple client certificates to be configured which would depend > upon the origin being contacted. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Resolved] (TS-4986) Memory leak in test_Map
[
https://issues.apache.org/jira/browse/TS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call resolved TS-4986.
Resolution: Fixed
> Memory leak in test_Map
> ---
>
> Key: TS-4986
> URL: https://issues.apache.org/jira/browse/TS-4986
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Tests
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.1.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
> =
> ==22202==ERROR: LeakSanitizer: detected memory leaks
> Direct leak of 3216 byte(s) in 134 object(s) allocated from:
> #0 0x7f4d3de22ea0 in operator new(unsigned long)
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x402df9 in test_TSHashTable()
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:76
> #2 0x402380 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:214
> #3 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 112 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x406576 in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x406576 in Vec 2>::set_expand() ../../lib/ts/Vec.h:781
> #4 0x406576 in HashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:552
> #5 0x401d90 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:174
> #6 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in ChainHashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:691
> #6 0x401f26 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:196
> #7 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de22ea0 in operator new(unsigned long)
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x402d4a in test_TSHashTable()
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:73
> #2 0x402380 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:214
> #3 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in ChainHashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:691
> #6 0x401efe in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:194
> #7 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in ChainHashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:691
> #6 0x401f12 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:195
> #7 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in
[jira] [Updated] (TS-4986) Memory leak in test_Map
[
https://issues.apache.org/jira/browse/TS-4986?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Bryan Call updated TS-4986:
---
Fix Version/s: 7.1.0
> Memory leak in test_Map
> ---
>
> Key: TS-4986
> URL: https://issues.apache.org/jira/browse/TS-4986
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, Tests
>Reporter: Bryan Call
>Assignee: Bryan Call
> Fix For: 7.1.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
> =
> ==22202==ERROR: LeakSanitizer: detected memory leaks
> Direct leak of 3216 byte(s) in 134 object(s) allocated from:
> #0 0x7f4d3de22ea0 in operator new(unsigned long)
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x402df9 in test_TSHashTable()
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:76
> #2 0x402380 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:214
> #3 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 112 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x406576 in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x406576 in Vec 2>::set_expand() ../../lib/ts/Vec.h:781
> #4 0x406576 in HashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:552
> #5 0x401d90 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:174
> #6 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in ChainHashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:691
> #6 0x401f26 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:196
> #7 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de22ea0 in operator new(unsigned long)
> (/lib64/libasan.so.3+0xc7ea0)
> #1 0x402d4a in test_TSHashTable()
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:73
> #2 0x402380 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:214
> #3 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in ChainHashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:691
> #6 0x401efe in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:194
> #7 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in ChainHashMap DefaultAlloc>::put(char const*, int) ../../lib/ts/Map.h:691
> #6 0x401f12 in main
> /home/bcall/dev/apache/trafficserver/lib/ts/test_Map.cc:195
> #7 0x7f4d3b09b730 in __libc_start_main (/lib64/libc.so.6+0x20730)
> Direct leak of 24 byte(s) in 1 object(s) allocated from:
> #0 0x7f4d3de21e60 in malloc (/lib64/libasan.so.3+0xc6e60)
> #1 0x7f4d3db28f85 in ats_malloc
> /home/bcall/dev/apache/trafficserver/lib/ts/ink_memory.cc:59
> #2 0x4126bf in DefaultAlloc::alloc(int) ../../lib/ts/defalloc.h:34
> #3 0x4126bf in ConsCell DefaultAlloc>::operator new(unsigned long) ../../lib/ts/List.h:603
> #4 0x4126bf in List DefaultAlloc>::List(MapElem) ../../lib/ts/List.h:663
> #5 0x4126bf in
[jira] [Created] (TS-5023) Allow diags.log and traffic.out to be rotated by size or time
Daniel Xu created TS-5023: - Summary: Allow diags.log and traffic.out to be rotated by size or time Key: TS-5023 URL: https://issues.apache.org/jira/browse/TS-5023 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Daniel Xu Create a 3rd option for diags.log and traffic.out to be rolled by time OR size. Currently access logs have this feature and diagnostic logs don't. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-5023) Allow diags.log and traffic.out to be rotated by size or time
[ https://issues.apache.org/jira/browse/TS-5023?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Xu reassigned TS-5023: - Assignee: Daniel Xu > Allow diags.log and traffic.out to be rotated by size or time > - > > Key: TS-5023 > URL: https://issues.apache.org/jira/browse/TS-5023 > Project: Traffic Server > Issue Type: Improvement > Components: Logging >Reporter: Daniel Xu >Assignee: Daniel Xu > > Create a 3rd option for diags.log and traffic.out to be rolled by time OR > size. Currently access logs have this feature and diagnostic logs don't. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-4399) Management API breaks diagnostic log rotation
[
https://issues.apache.org/jira/browse/TS-4399?focusedWorklogId=31346=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31346
]
ASF GitHub Bot logged work on TS-4399:
--
Author: ASF GitHub Bot
Created on: 31/Oct/16 16:38
Start Date: 31/Oct/16 16:38
Worklog Time Spent: 10m
Work Description: Github user danobi commented on the issue:
https://github.com/apache/trafficserver/pull/1073
The actual issue was suspected issue #1, where there was a sleeping
deadlock scenario. See commit message for details.
Other than that most recent change, I think the patch is ready for final
review.
Issue Time Tracking
---
Worklog Id: (was: 31346)
Time Spent: 1h 50m (was: 1h 40m)
> Management API breaks diagnostic log rotation
> -
>
> Key: TS-4399
> URL: https://issues.apache.org/jira/browse/TS-4399
> Project: Traffic Server
> Issue Type: Bug
> Components: Logging, Management API
>Reporter: James Peach
>Assignee: Daniel Xu
> Fix For: 7.1.0
>
> Time Spent: 1h 50m
> Remaining Estimate: 0h
>
> Start up Traffic Server:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.02 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26952 26951 0 10:13AM ?? 0:00.08 /opt/ats/bin/traffic_server
> -M --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out --httpport 8080:fd=12
> {code}
> Now restart it using {{traffic_line -S}} followed by {{traffic_line -U}}:
> {code}
> 0 26950 1 0 10:13AM ?? 0:00.01 /opt/ats/bin/traffic_cop
>-2 26951 26950 0 10:13AM ?? 0:00.05 /opt/ats/bin/traffic_manager
> --bind_stdout /opt/ats/var/log/trafficserver/traffic.out --bind_stderr
> /opt/ats/var/log/trafficserver/traffic.out
>-2 26967 26951 0 10:13AM ?? 0:00.12 /opt/ats/bin/traffic_server
> -M --httpport 8080:fd=20
> {code}
> Note that we lost the {{\--bind_stdout}} and {{\--bind_stderr}} options.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver issue #1073: TS-4399 TS-4400 Management API messes up proxy op...
Github user danobi commented on the issue: https://github.com/apache/trafficserver/pull/1073 The actual issue was suspected issue #1, where there was a sleeping deadlock scenario. See commit message for details. Other than that most recent change, I think the patch is ready for final review. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Work logged] (TS-4978) CID 1364311: Memory - illegal accesses (USE_AFTER_FREE) in iocore/net/SSLConfig.cc
[
https://issues.apache.org/jira/browse/TS-4978?focusedWorklogId=31345=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-31345
]
ASF GitHub Bot logged work on TS-4978:
--
Author: ASF GitHub Bot
Created on: 31/Oct/16 15:23
Start Date: 31/Oct/16 15:23
Worklog Time Spent: 10m
Work Description: Github user persiaAziz commented on the issue:
https://github.com/apache/trafficserver/pull/1120
I will do a local merge and then make a new PR
Issue Time Tracking
---
Worklog Id: (was: 31345)
Time Spent: 1h 10m (was: 1h)
> CID 1364311: Memory - illegal accesses (USE_AFTER_FREE) in
> iocore/net/SSLConfig.cc
>
>
> Key: TS-4978
> URL: https://issues.apache.org/jira/browse/TS-4978
> Project: Traffic Server
> Issue Type: Bug
> Components: TLS
>Reporter: Leif Hedstrom
>Assignee: Syeda Persia Aziz
> Fix For: 7.1.0
>
> Time Spent: 1h 10m
> Remaining Estimate: 0h
>
> I think this is perhaps from TS-4858:
> {code}
> *** CID 1364311: Memory - illegal accesses (USE_AFTER_FREE)
> /iocore/net/SSLConfig.cc: 258 in SSLConfigParams::initialize()()
> 252 ats_free(ssl_server_ca_cert_filename);
> 253 ats_free(CACertRelativePath);
> 254
> 255 #if HAVE_OPENSSL_SESSION_TICKETS
> 256 REC_ReadConfigStringAlloc(ticket_key_filename,
> "proxy.config.ssl.server.ticket_key.filename");
> 257 if (this->ticket_key_filename != NULL) {
>CID 1364311: Memory - illegal accesses (USE_AFTER_FREE)
>Passing freed pointer "this->ticket_key_filename" as an argument to
> "relative_to".
> 258 ats_scoped_str
> ticket_key_path(Layout::relative_to(this->serverCertPathOnly,
> this->ticket_key_filename));
> 259 default_global_keyblock =
> ssl_create_ticket_keyblock(ticket_key_path);
> 260 } else {
> 261 default_global_keyblock = ssl_create_ticket_keyblock(NULL);
> 262 }
> 263 #endif
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver issue #1120: TS-4978: illegal memory access with ticket_key.fi...
Github user persiaAziz commented on the issue: https://github.com/apache/trafficserver/pull/1120 I will do a local merge and then make a new PR --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
