[jira] [Commented] (TS-1979) Investigate body factory and its use of malloc()
[ https://issues.apache.org/jira/browse/TS-1979?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15564251#comment-15564251 ] Jari Alhonen commented on TS-1979: -- Alan, I'm getting ready to work on the body factory improvements; can you please post the stuff you have made, if they are still relevant? Thanks. > Investigate body factory and its use of malloc() > > > Key: TS-1979 > URL: https://issues.apache.org/jira/browse/TS-1979 > Project: Traffic Server > Issue Type: Improvement > Components: HTTP >Reporter: Leif Hedstrom >Assignee: Jari Alhonen > Fix For: 7.2.0 > > > It might be a nice optimization to make it use heap allocation (that is, put > the body factory on the freelist) for small bodies. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #1081: TS-3204: Crash when body_factory file is empty
Github user alhonen commented on the issue: https://github.com/apache/trafficserver/pull/1081 In load_from_file(). If the file length is 0, it allocates a buffer with size 1 for the terminating NULL, and returns that with length 0. --- 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 #1081: TS-3204: Crash when body_factory file is e...
GitHub user alhonen opened a pull request: https://github.com/apache/trafficserver/pull/1081 TS-3204: Crash when body_factory file is empty Set internal buffer to null for empty files to not follow the crash-prone execution path. You can merge this pull request into a Git repository by running: $ git pull https://github.com/alhonen/trafficserver TS-3204 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/1081.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 #1081 commit 49f1d8f011eeb69dcb8ecf45232c68d13ae32aef Author: Jari Alhonen <jar...@gmail.com> Date: 2016-10-04T01:18:05Z TS-3204: Crash when body_factory file is empty Set internal buffer to null for empty files to not follow the crash-prone execution path. --- 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-2258) Verify that all fields are correct in RecordsConfig.cc
[ https://issues.apache.org/jira/browse/TS-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jari Alhonen updated TS-2258: - Assignee: (was: Jari Alhonen) > Verify that all fields are correct in RecordsConfig.cc > -- > > Key: TS-2258 > URL: https://issues.apache.org/jira/browse/TS-2258 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Leif Hedstrom > Labels: newbie > Fix For: 7.1.0 > > Time Spent: 7h 40m > Remaining Estimate: 0h > > We should go through every configuration in RecordsConfig.cc, and assure that > fields such as if it's dynamically reloadable or not, validation regexes etc. > are all set 100% correct. > Once this file is accurate, and will be the one true authoritative source for > everything "configuration"; it can be used for command line help (e.g. > traffic_line can say if a config is reloadable), and we can even use it as a > source for the Sphinx documentation. > A bonus would be to add a one-line helper line for each configuration in > RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new > type of tools to help managing configurations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-2258) Verify that all fields are correct in RecordsConfig.cc
[ https://issues.apache.org/jira/browse/TS-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15508413#comment-15508413 ] Jari Alhonen commented on TS-2258: -- There is plenty more, 887 was just a start. But I would rather focus on other things at the moment, someone else can pick this up. > Verify that all fields are correct in RecordsConfig.cc > -- > > Key: TS-2258 > URL: https://issues.apache.org/jira/browse/TS-2258 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Leif Hedstrom >Assignee: Jari Alhonen > Labels: newbie > Fix For: 7.1.0 > > Time Spent: 7h 40m > Remaining Estimate: 0h > > We should go through every configuration in RecordsConfig.cc, and assure that > fields such as if it's dynamically reloadable or not, validation regexes etc. > are all set 100% correct. > Once this file is accurate, and will be the one true authoritative source for > everything "configuration"; it can be used for command line help (e.g. > traffic_line can say if a config is reloadable), and we can even use it as a > source for the Sphinx documentation. > A bonus would be to add a one-line helper line for each configuration in > RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new > type of tools to help managing configurations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-2258) Verify that all fields are correct in RecordsConfig.cc
[ https://issues.apache.org/jira/browse/TS-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jari Alhonen updated TS-2258: - Assignee: (was: Jari Alhonen) > Verify that all fields are correct in RecordsConfig.cc > -- > > Key: TS-2258 > URL: https://issues.apache.org/jira/browse/TS-2258 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Leif Hedstrom > Labels: newbie > Fix For: 7.1.0 > > Time Spent: 7h > Remaining Estimate: 0h > > We should go through every configuration in RecordsConfig.cc, and assure that > fields such as if it's dynamically reloadable or not, validation regexes etc. > are all set 100% correct. > Once this file is accurate, and will be the one true authoritative source for > everything "configuration"; it can be used for command line help (e.g. > traffic_line can say if a config is reloadable), and we can even use it as a > source for the Sphinx documentation. > A bonus would be to add a one-line helper line for each configuration in > RecordsConfig.cc. This can again be used for e.g. traffic_line, or for a new > type of tools to help managing configurations. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1992) Examine mgmt/RecordsConfig.cc, add validation where it makes sense
[
https://issues.apache.org/jira/browse/TS-1992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jari Alhonen updated TS-1992:
-
Assignee: (was: Jari Alhonen)
> Examine mgmt/RecordsConfig.cc, add validation where it makes sense
> --
>
> Key: TS-1992
> URL: https://issues.apache.org/jira/browse/TS-1992
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration
>Reporter: Igor Galić
> Labels: newbie
> Fix For: 7.2.0
>
>
> example:
> {code}
> {RECT_CONFIG, "proxy.config.http.cache.required_headers", RECD_INT, "2",
> RECU_DYNAMIC, RR_NULL, RECC_NULL, NULL, RECA_NULL}
> {code}
> We should change this to
> {code}
> {RECT_CONFIG, "proxy.config.http.cache.required_headers", RECD_INT, "2",
> RECU_DYNAMIC, RR_NULL, RECC_NULL, "[0-2]", RECA_NULL}
> {code}
> which are the valid values for this config.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-2602) Support continuation lines in regex_remap configs
[
https://issues.apache.org/jira/browse/TS-2602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jari Alhonen updated TS-2602:
-
Assignee: (was: Jari Alhonen)
> Support continuation lines in regex_remap configs
> -
>
> Key: TS-2602
> URL: https://issues.apache.org/jira/browse/TS-2602
> Project: Traffic Server
> Issue Type: New Feature
> Components: Plugins
>Reporter: Leif Hedstrom
> Labels: newbie
> Fix For: 7.2.0
>
>
> With the introduction of overridable configurations (TS-2585), regex_remap
> rules can now be fairly long. It'd be swell to support continuation lines,
> e.g.
> {code}
> . http://www.ogre.com/ \
> @proxy.config.http.insert_response_via_str=1 \
> @proxy.config.http.background_fill_completed_threshold=0.75
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-2798) TLS client configuration is not really reloadable
[ https://issues.apache.org/jira/browse/TS-2798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jari Alhonen reassigned TS-2798: Assignee: (was: Jari Alhonen) > TLS client configuration is not really reloadable > - > > Key: TS-2798 > URL: https://issues.apache.org/jira/browse/TS-2798 > Project: Traffic Server > Issue Type: Bug > Components: Configuration, SSL >Reporter: Greg Henry > Fix For: 7.1.0 > > > Cannot reload SSL client config. It appears to but does not work. > Made changes to reflect a Cert file. It would not work without a complete > restart of ATS. Should have been a traffic_line -x -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver pull request #887: TS-2258: Mark whether configs are reloadabl...
Github user alhonen commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/887#discussion_r79533983
--- Diff: mgmt/FileManager.cc ---
@@ -602,9 +600,9 @@ FileManager::WalkSnaps(ExpandingArray *snapList)
{
MFresult r;
- // The original code reset this->managedDir from
proxy.config.snapshot_dir at this point. There doesn't appear to be
- // any need for that, since managedDir is always set in the constructor
and should not be changed.
- ink_release_assert(this->managedDir != NULL);
+ // Make sure managedDir is the latest from proxy.config.snapshot_dir.
+ ats_scoped_str snapshotDir(RecConfigReadSnapshotDir());
+ this->managedDir = snapshotDir;
--- End diff --
Done.
---
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 #887: TS-2258: Mark whether configs are reloadabl...
Github user alhonen commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/887#discussion_r78891906
--- Diff: mgmt/RecordsConfig.cc ---
@@ -103,10 +103,10 @@ static const RecordElement RecordsConfig[] =
,
{RECT_CONFIG, "proxy.config.output.logfile.rolling_size_mb", RECD_INT,
"100", RECU_DYNAMIC, RR_NULL, RECC_STR, "^0*[1-9][0-9]*$", RECA_NULL}
,
- {RECT_CONFIG, "proxy.config.snapshot_dir", RECD_STRING, "snapshots",
RECU_NULL, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.snapshot_dir", RECD_STRING, "snapshots",
RECU_DYNAMIC, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
--- End diff --
Right. It seems you changed this behaviour
(67306a71da65f135ff85c2f4d9b966122fa5590a). Should we change it back?
---
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 #887: TS-2258: Mark whether configs are reloadabl...
Github user alhonen commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/887#discussion_r78890394
--- Diff: mgmt/RecordsConfig.cc ---
@@ -815,33 +815,33 @@ static const RecordElement RecordsConfig[] =
#endif
RECU_DYNAMIC, RR_NULL, RECC_INT, "[0-65535]", RECA_NULL}
,
- {RECT_CONFIG, "proxy.config.net.sock_recv_buffer_size_in", RECD_INT,
"0", RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.net.sock_recv_buffer_size_in", RECD_INT,
"0", RECU_RESTART_TS, RR_NULL, RECC_STR, "^[0-9]+$", RECA_NULL}
--- End diff --
Ok, TS-4869 created.
---
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] [Created] (TS-4869) Change the default config validation of RECD_INT to "^[0-9]+$"
Jari Alhonen created TS-4869: Summary: Change the default config validation of RECD_INT to "^[0-9]+$" Key: TS-4869 URL: https://issues.apache.org/jira/browse/TS-4869 Project: Traffic Server Issue Type: Improvement Reporter: Jari Alhonen The config validation for RECD_INT currently takes in things like "234fdg" without errors, interpreting that as 234. Should instead validate the whole string. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #887: TS-2258: Mark whether configs are reloadable (part...
Github user alhonen commented on the issue: https://github.com/apache/trafficserver/pull/887 Just pushed a version to resolve the merge conflict, and also a change for the ui_enabled, which testing proved to be dynamic. --- 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 #887: TS-2258: Mark whether configs are reloadabl...
Github user alhonen commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/887#discussion_r75984645
--- Diff: mgmt/RecordsConfig.cc ---
@@ -103,10 +103,10 @@ static const RecordElement RecordsConfig[] =
,
{RECT_CONFIG, "proxy.config.output.logfile.rolling_size_mb", RECD_INT,
"100", RECU_DYNAMIC, RR_NULL, RECC_STR, "^0*[1-9][0-9]*$", RECA_NULL}
,
- {RECT_CONFIG, "proxy.config.snapshot_dir", RECD_STRING, "snapshots",
RECU_NULL, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.snapshot_dir", RECD_STRING, "snapshots",
RECU_RESTART_TS, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
--- End diff --
It actually does look dynamic when checking it again, must have missed it
somehow. Will change.
---
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 #887: TS-2258: Mark whether configs are reloadabl...
Github user alhonen commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/887#discussion_r75984598
--- Diff: mgmt/RecordsConfig.cc ---
@@ -67,29 +67,29 @@ static const RecordElement RecordsConfig[] =
,
{RECT_CONFIG, "proxy.config.alarm_email", RECD_STRING, TS_PKGSYSUSER,
RECU_DYNAMIC, RR_NULL, RECC_STR, ".*", RECA_NULL}
,
- {RECT_CONFIG, "proxy.config.syslog_facility", RECD_STRING, "LOG_DAEMON",
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.syslog_facility", RECD_STRING, "LOG_DAEMON",
RECU_RESTART_TS, RR_NULL, RECC_STR, ".*", RECA_NULL}
,
//# Negative core limit means max out limit
- {RECT_CONFIG, "proxy.config.core_limit", RECD_INT, "-1", RECU_NULL,
RR_NULL, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.core_limit", RECD_INT, "-1",
RECU_RESTART_TS, RR_NULL, RECC_NULL, NULL, RECA_NULL}
,
{RECT_CONFIG, "proxy.config.crash_log_helper", RECD_STRING,
MGMT_CRASHLOG_HELPER, RECU_RESTART_TS, RR_NULL, RECC_NULL, NULL, RECA_NULL}
,
// 0 - Disabled, 1 - enabled for important pages (e.g. cache directory),
2 - enabled for all pages
- {RECT_CONFIG, "proxy.config.mlock_enabled", RECD_INT, "0", RECU_NULL,
RR_NULL, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.mlock_enabled", RECD_INT, "0",
RECU_RESTART_TS, RR_NULL, RECC_INT, "[0-2]", RECA_NULL}
,
- {RECT_CONFIG, "proxy.config.cop.core_signal", RECD_INT, "0", RECU_NULL,
RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.cop.core_signal", RECD_INT, "0",
RECU_RESTART_TC, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
, // needed by traffic_cop
- {RECT_CONFIG, "proxy.config.cop.linux_min_swapfree_kb", RECD_INT, "0",
RECU_NULL, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.cop.linux_min_swapfree_kb", RECD_INT, "0",
RECU_RESTART_TC, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
, // needed by traffic_cop
- {RECT_CONFIG, "proxy.config.cop.linux_min_memfree_kb", RECD_INT, "0",
RECU_NULL, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.cop.linux_min_memfree_kb", RECD_INT, "0",
RECU_RESTART_TC, RR_REQUIRED, RECC_NULL, NULL, RECA_NULL}
, // needed by traffic_cop
- {RECT_CONFIG, "proxy.config.cop.init_sleep_time", RECD_INT, "0",
RECU_NULL, RR_NULL, RECC_NULL, "[0-900]", RECA_NULL}
+ {RECT_CONFIG, "proxy.config.cop.init_sleep_time", RECD_INT, "0",
RECU_RESTART_TC, RR_NULL, RECC_INT, "[0-900]", RECA_NULL}
,
//# 0 = disable (seconds)
- {RECT_CONFIG, "proxy.config.dump_mem_info_frequency", RECD_INT, "0",
RECU_NULL, RR_NULL, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.dump_mem_info_frequency", RECD_INT, "0",
RECU_RESTART_TS, RR_NULL, RECC_NULL, NULL, RECA_NULL}
,
//# 0 = disable
- {RECT_CONFIG, "proxy.config.http_ui_enabled", RECD_INT, "0", RECU_NULL,
RR_NULL, RECC_NULL, NULL, RECA_NULL}
+ {RECT_CONFIG, "proxy.config.http_ui_enabled", RECD_INT, "0",
RECU_RESTART_TS, RR_NULL, RECC_NULL, NULL, RECA_NULL}
--- End diff --
Well, it's in the init of StatPagesManager, will check again on whether it
is dynamic enough.
---
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 #887: TS-2258: Mark whether configs are reloadabl...
GitHub user alhonen opened a pull request: https://github.com/apache/trafficserver/pull/887 TS-2258: Mark whether configs are reloadable (part 1) Only adding the information to a small number of the configurations. You can merge this pull request into a Git repository by running: $ git pull https://github.com/alhonen/trafficserver ts-2258-1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/887.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 #887 --- 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 #803: TS-4584: Resource leak, CID 1254818 and 1254809
Github user alhonen commented on the issue: https://github.com/apache/trafficserver/pull/803 Scoped pointer approach posted. --- 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 #803: TS-4584: Resource leak, CID 1254818 and 1254809
Github user alhonen commented on the issue: https://github.com/apache/trafficserver/pull/803 I'm testing the scoped pointer approach 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. ---
[GitHub] trafficserver issue #802: TS-4583: Null-pointer dereference after check
Github user alhonen commented on the issue: https://github.com/apache/trafficserver/pull/802 If they indeed do go NULL together (a bit hard to verify), then we can change the null check instead. I'll modify it thus. --- 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 #803: TS-4584: Resource leak, CID 1254818 and 125...
GitHub user alhonen opened a pull request: https://github.com/apache/trafficserver/pull/803 TS-4584: Resource leak, CID 1254818 and 1254809 Coverity issues CID 1254818 and 1254809, a resource leak on file descriptor and allocated memory. You can merge this pull request into a Git repository by running: $ git pull https://github.com/alhonen/trafficserver TS-4584 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/803.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 #803 commit dfd4c50fcbd1a90d329e3efc296e44af6022a6f1 Author: Jari Alhonen <jar...@gmail.com> Date: 2016-07-17T04:55:47Z TS-4584: Resource leak, CID 1254818 and 1254809 Coverity issues CID 1254818 and 1254809, a resource leak on file descriptor and allocated memory. --- 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 #802: TS-4583: Null-pointer dereference after che...
GitHub user alhonen opened a pull request: https://github.com/apache/trafficserver/pull/802 TS-4583: Null-pointer dereference after check Fixes Coverity issue CID 1021958: HttpSM.cc checks server_entry against NULL, suggesting it might be NULL, before calling release_server_session(), which dereferences server_entry. You can merge this pull request into a Git repository by running: $ git pull https://github.com/alhonen/trafficserver TS-4583 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/802.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 #802 commit cf5da38f2976e2f08d1279977c9aafbbb44f Author: Jari Alhonen <jari_alho...@apple.com> Date: 2016-07-17T04:26:22Z TS-4583: Null-pointer dereference after check Fixes Coverity issue CID 1021958: HttpSM.cc checks server_entry against NULL, suggesting it might be NULL, before calling release_server_session(), which dereferences server_entry. --- 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] [Assigned] (TS-3726) Expose build_error_response in order to making a formated error response in plugin
[ https://issues.apache.org/jira/browse/TS-3726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jari Alhonen reassigned TS-3726: Assignee: Oknet Xu (was: Jari Alhonen) > Expose build_error_response in order to making a formated error response in > plugin > -- > > Key: TS-3726 > URL: https://issues.apache.org/jira/browse/TS-3726 > Project: Traffic Server > Issue Type: New Feature > Components: TS API >Reporter: Oknet Xu >Assignee: Oknet Xu > Labels: API, review > Fix For: 7.0.0 > > Attachments: TSHttpTxnErrorpageSet.patch > > > expose build_error_response in order to making a formated error response in > plugin. > ATS support multi-language error response page by body_factory. > In the ATS internal, build_error_response used to generating it. > I wrote a patch to expose build_error_response function for plugin. > and modified example/basic_auth for a sample usage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3726) Expose build_error_response in order to making a formated error response in plugin
[ https://issues.apache.org/jira/browse/TS-3726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15356656#comment-15356656 ] Jari Alhonen commented on TS-3726: -- This would still seem to lack a PR on GitHub? > Expose build_error_response in order to making a formated error response in > plugin > -- > > Key: TS-3726 > URL: https://issues.apache.org/jira/browse/TS-3726 > Project: Traffic Server > Issue Type: New Feature > Components: TS API >Reporter: Oknet Xu > Assignee: Jari Alhonen > Labels: API, review > Fix For: 7.0.0 > > Attachments: TSHttpTxnErrorpageSet.patch > > > expose build_error_response in order to making a formated error response in > plugin. > ATS support multi-language error response page by body_factory. > In the ATS internal, build_error_response used to generating it. > I wrote a patch to expose build_error_response function for plugin. > and modified example/basic_auth for a sample usage. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4584) CID 1254818: Resource leak on file descriptor and allocated memory
[ https://issues.apache.org/jira/browse/TS-4584?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jari Alhonen reassigned TS-4584: Assignee: Jari Alhonen > CID 1254818: Resource leak on file descriptor and allocated memory > -- > > Key: TS-4584 > URL: https://issues.apache.org/jira/browse/TS-4584 > Project: Traffic Server > Issue Type: Bug > Reporter: Jari Alhonen > Assignee: Jari Alhonen > > ClusterMachine.cc leaks file descriptors and allocated memory in certain > error conditions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4584) CID 1254818: Resource leak on file descriptor and allocated memory
Jari Alhonen created TS-4584: Summary: CID 1254818: Resource leak on file descriptor and allocated memory Key: TS-4584 URL: https://issues.apache.org/jira/browse/TS-4584 Project: Traffic Server Issue Type: Bug Reporter: Jari Alhonen ClusterMachine.cc leaks file descriptors and allocated memory in certain error conditions. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-4583) CID 1021958: Null-pointer dereference after check
Jari Alhonen created TS-4583: Summary: CID 1021958: Null-pointer dereference after check Key: TS-4583 URL: https://issues.apache.org/jira/browse/TS-4583 Project: Traffic Server Issue Type: Bug Reporter: Jari Alhonen HttpSM.cc checks server_entry against NULL, suggesting it might be NULL, before calling release_server_session(), which dereferences server_entry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4583) CID 1021958: Null-pointer dereference after check
[ https://issues.apache.org/jira/browse/TS-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jari Alhonen reassigned TS-4583: Assignee: Jari Alhonen > CID 1021958: Null-pointer dereference after check > - > > Key: TS-4583 > URL: https://issues.apache.org/jira/browse/TS-4583 > Project: Traffic Server > Issue Type: Bug > Reporter: Jari Alhonen > Assignee: Jari Alhonen > > HttpSM.cc checks server_entry against NULL, suggesting it might be NULL, > before calling release_server_session(), which dereferences server_entry. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
