[jira] [Updated] (TS-3831) Overridable error response type
[ https://issues.apache.org/jira/browse/TS-3831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Syeda Persia Aziz updated TS-3831: -- Description: ATS has a set of error pages in the folder body_factory, namely access#denied.html, access#proxy_auth_required.html,connect#dns_failed.html... etc. All these error pages are loaded in a RawHashTable. When there is an error for e.g. access denied, ATS builds a error response of type access#denied. We can have an overridable config that will decide which custom error page to send to the client. This config will be set per remap rule. We can have the custom error pages in the body_factory folder and these pages will follow a specific naming convention for e.g. $var_access#denied.html, $var_proxy_auth_required.html, ….. Here $var is the overridable config (proxy.config.error.response.type). Example: in Remap.config map www.abcxyz.com www.efgijk.com @plugin=config.so @pparam=proxy.config.error.response.type=yahoo Now, if there is for e.g. a 'access denied' error, the build_error_response will build a customized error response of type yahoo_access#denied . If it can not find the type yahoo_access#denied, then it will simply build the default access#denied error response. Note: I already have a patch for this. I am thinking of test cases. was: ATS has a set of error pages in the folder body_factory, namely access#denied.html, access#proxy_auth_required.html,connect#dns_failed.html... etc. All these error pages are loaded in a RawHashTable. When there is an error for e.g. access denied, ATS builds a error response of type access#denied. We can have an overridable config that will decide which custom error page to send to the client. This config will be set per remap rule. We can have the custom error pages in the body_factory folder and these pages will follow a specific naming convention for e.g. $var_access#denied.html, $var_proxy_auth_required.html, ….. Here $var is the overridable config (proxy.config.error.response.type). Example: in Remap.config map www.abcxyz.com www.efgijk.com @plugin=config.so @pparam=proxy.config.error.response.type=yahoo Now, if there is for e.g. a 'access denied' error, the build_error_response will build a customized error response of type yahoo_access#denied . If it can not find the type yahoo_access#denied, then it will simply build the default access#denied error response. I already have a patch for this Overridable error response type --- Key: TS-3831 URL: https://issues.apache.org/jira/browse/TS-3831 Project: Traffic Server Issue Type: New Feature Components: Configuration Reporter: Syeda Persia Aziz ATS has a set of error pages in the folder body_factory, namely access#denied.html, access#proxy_auth_required.html,connect#dns_failed.html... etc. All these error pages are loaded in a RawHashTable. When there is an error for e.g. access denied, ATS builds a error response of type access#denied. We can have an overridable config that will decide which custom error page to send to the client. This config will be set per remap rule. We can have the custom error pages in the body_factory folder and these pages will follow a specific naming convention for e.g. $var_access#denied.html, $var_proxy_auth_required.html, ….. Here $var is the overridable config (proxy.config.error.response.type). Example: in Remap.config map www.abcxyz.com www.efgijk.com @plugin=config.so @pparam=proxy.config.error.response.type=yahoo Now, if there is for e.g. a 'access denied' error, the build_error_response will build a customized error response of type yahoo_access#denied . If it can not find the type yahoo_access#denied, then it will simply build the default access#denied error response. Note: I already have a patch for this. I am thinking of test cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3831) Overridable error response type
[ https://issues.apache.org/jira/browse/TS-3831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Syeda Persia Aziz updated TS-3831: -- Description: ATS has a set of error pages in the folder body_factory, namely access#denied.html, access#proxy_auth_required.html,connect#dns_failed.html... etc. All these error pages are loaded in a RawHashTable. When there is an error for e.g. access denied, ATS builds a error response of type access#denied. We can have an overridable config that will decide which custom error page to send to the client. This config will be set per remap rule. We can have the custom error pages in the body_factory folder and these pages will follow a specific naming convention for e.g. $var_access#denied.html, $var_proxy_auth_required.html, ….. Here $var is the overridable config (proxy.config.error.response.type). Example: in Remap.config map www.abcxyz.com www.efgijk.com @plugin=config.so @pparam=proxy.config.error.response.type=yahoo Now, if there is for e.g. a 'access denied' error, the build_error_response will build a customized error response of type yahoo_access#denied . If it can not find the type yahoo_access#denied, then it will simply build the default access#denied error response. I already have a patch for this was: ATS has a set of error pages in the folder body_factory, namely access#denied.html, access#proxy_auth_required.html,connect#dns_failed.html... etc. All these error pages are loaded in a RawHashTable. When there is an error for e.g. access denied, ATS builds a error response of type access#denied. We can have an overridable config that will decide which custom error page to send to the client. This config will be set per remap rule. We can have the custom error pages in the body_factory folder and these pages will follow a specific naming convention for e.g. $var_access#denied.html, $var_proxy_auth_required.html, ….. Here $var is the overridable config (proxy.config.error.response.type). Example: in Remap.config map www.abcxyz.com www.efgijk.com @plugin=config.so @pparam=proxy.config.error.response.type=yahoo Now, if there is for e.g. a 'access denied' error, the build_error_response will build a customized error response of type yahoo_access#denied . If it can not find the type yahoo_access#denied, then it will simply build the default access#denied error response. Overridable error response type --- Key: TS-3831 URL: https://issues.apache.org/jira/browse/TS-3831 Project: Traffic Server Issue Type: New Feature Components: Configuration Reporter: Syeda Persia Aziz ATS has a set of error pages in the folder body_factory, namely access#denied.html, access#proxy_auth_required.html,connect#dns_failed.html... etc. All these error pages are loaded in a RawHashTable. When there is an error for e.g. access denied, ATS builds a error response of type access#denied. We can have an overridable config that will decide which custom error page to send to the client. This config will be set per remap rule. We can have the custom error pages in the body_factory folder and these pages will follow a specific naming convention for e.g. $var_access#denied.html, $var_proxy_auth_required.html, ….. Here $var is the overridable config (proxy.config.error.response.type). Example: in Remap.config map www.abcxyz.com www.efgijk.com @plugin=config.so @pparam=proxy.config.error.response.type=yahoo Now, if there is for e.g. a 'access denied' error, the build_error_response will build a customized error response of type yahoo_access#denied . If it can not find the type yahoo_access#denied, then it will simply build the default access#denied error response. I already have a patch for this -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3821) Segmentation fault possibly due leaks in atscppapi
[
https://issues.apache.org/jira/browse/TS-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661847#comment-14661847
]
Leif Hedstrom commented on TS-3821:
---
[~briang] Is there anything we can do in the core here to make this better /
more informative to plugin writers? I'm wondering if TS-2645 is also a plugin
bug? I know they use a lot of custom code as well over at D.
Segmentation fault possibly due leaks in atscppapi
--
Key: TS-3821
URL: https://issues.apache.org/jira/browse/TS-3821
Project: Traffic Server
Issue Type: Bug
Components: CPP API
Reporter: Jiri Podhorsky
Assignee: Brian Geffon
Fix For: 6.1.0
Attachments: AlwaysCache.cc, BlockIP.cc, EditHeader.cc
Hello,
I'm getting segmentation faults with ATS 5.3.1, possibly when I enabled
plugins in atscppapi, in which are used other Plugins than GlobalPlugin
(TransformationPlugin, InterceptionPlugin,...)
i'm building traffic server only with parameters:
./configure --prefix=/install --exec-prefix=/exec --with-user=trafficserver
--enable-cppapi
I'm getting segfault:
{noformat}
traffic_server: Segmentation fault (Address not mapped to object [(nil)])
traffic_server - STACK TRACE:
/www/trafficserver/install/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4c64d9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x2afbe25d90a0]
{noformat}
I tried to find an Issue and found possible leak in dectructor ~Transaction()
of Transaction.cc file.
The leak is, there is added plugin by addPlugin(TransactionPlugin *);
and according to documentation
[https://docs.trafficserver.apache.org/en/latest/api/classatscppapi_1_1Transaction.html#a9835e610553275d197cabfbd6d1cab7b],
Transaction should be responsible for cleaning.
But nothing removes items of list state_.plugins_, where should be pointers
to memory allocated with new, which won't be deleted by delete state_;
I tried to correct it with
{noformat}
for (TransactionPlugin* tmp : state_-plugins_) {
delete tmp;
}
{noformat}
But it didn't work. I'm getting similar segfault with another
{noformat}
traffic_server: Segmentation fault (Invalid permissions for mapped object
[0x2b86141ea898])
traffic_server - STACK TRACE:
/www/trafficserver/install/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4c64d9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x2b85d603d0a0]
[0x2b86141ea898]
{noformat}
I tried to find more deep and find the plugins should be freed by delete in
another class in file utils_internal.cc.
But if this is true, I should see in debug mode message, which is printed
before delete:
{noformat}
LOG_DEBUG(Locked Mutex...Deleting transaction plugin at %p, *iter);
{noformat}
But I don't see such messages in log.
I can see in error.log lot of these messages. I'm getting them at least every
second.
{noformat}
20150805.16h37m04s [atscppapi] [Transaction.cc:343, operator()()] server
request already initialized
{noformat}
Can you help me find the issue? Thanks for help in advance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3831) Overridable error response type
[ https://issues.apache.org/jira/browse/TS-3831?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662526#comment-14662526 ] ASF GitHub Bot commented on TS-3831: GitHub user persiaAziz opened a pull request: https://github.com/apache/trafficserver/pull/273 TS-3831: overridable error response type Provision for custom error page You can merge this pull request into a Git repository by running: $ git pull https://github.com/persiaAziz/trafficserver TS-3831 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/273.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 #273 commit ee73fa5f7702d5ef1bcf1b723867cca95524ae63 Author: Syeda Persia Aziz persia.a...@yahoo.com Date: 2015-08-07T21:55:29Z TS-3831: overridable error response type commit 1d28d70af6d67b533082aa1d44137897485cfd4e Author: Syeda Persia Aziz persia.a...@yahoo.com Date: 2015-08-07T22:00:37Z remove whitespaces Overridable error response type --- Key: TS-3831 URL: https://issues.apache.org/jira/browse/TS-3831 Project: Traffic Server Issue Type: New Feature Components: Configuration Reporter: Syeda Persia Aziz ATS has a set of error pages in the folder body_factory, namely access#denied, access#proxy_auth_required,connect#dns_failed... etc. All these error pages are loaded in a RawHashTable. When there is an error for e.g. access denied, ATS builds a error response of type access#denied. We can have an overridable config that will decide which custom error page to send to the client. This config will be set per remap rule. We can have the custom error pages in the body_factory folder and these pages will follow a specific naming convention for e.g. $var_access#denied, $var_proxy_auth_required, ….. Here $var is the overridable config (proxy.config.error.response.type). Example: in Remap.config map www.abcxyz.com www.efgijk.com @plugin=config.so @pparam=proxy.config.error.response.type=yahoo Now, if there is for e.g. a 'access denied' error, the build_error_response will build a customized error response of type yahoo_access#denied . If it can not find the type yahoo_access#denied, then it will simply build the default access#denied error response. Note: I already have a patch for this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-306) enable log rotation for diags.log
[ https://issues.apache.org/jira/browse/TS-306?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662592#comment-14662592 ] ASF GitHub Bot commented on TS-306: --- GitHub user danobi opened a pull request: https://github.com/apache/trafficserver/pull/274 TS-306 Enable log rotation for diags.log traffic.out - The commit message contains an architectural overview of this feature - 'make test' and './traffic_server -R 1' all pass right now - Manual testing yields correct rotational behavior and unchanged behavior to access error logs (eg. squid.log, error.log, etc) - Documentation is coming soon You can merge this pull request into a Git repository by running: $ git pull https://github.com/danobi/trafficserver log-rotation-squashed Alternatively you can review and apply these changes as the patch at: https://github.com/apache/trafficserver/pull/274.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 #274 commit 7be0a0d7f44505af2d2aa5e2ce85fb7e8c478a9e Author: Daniel Xu danie...@yahoo-inc.com Date: 2015-07-13T23:07:30Z TS-306 Enable log rotation for diags.log traffic.out This feature provides the ability to rotate any log that is created by the Diags (including diags.log and manager.log) class, as well as traffic.out (the output log). These logs can be rotated either by time or by size, and both of these options can be specified in records.config [see documentation]. While the feature is relatively small, it required a rather large number of internal changes. Therefore, the _rest_ of this commit message will be a high level architectural overview of the changes necessitated by this feature. The class, BaseLogFile, is added and it is intended to be an abstraction for files on disk as well as the stdout/stderr stream. BaseLogFile is used by both LogFile and Diags to help control individual log files. For Diags, each BaseLogFile is created by DiagsConfig. DiagsConfig also sets a few more values unavailable to Diags. LogFile uses BaseLogFile to manage actual files on disk. In some rare cases, LogFile also uses BaseLogFile to manage a stdout or stderr stream. Most of the functionality in BaseLogFile was stripped from LogFile and moved into BaseLogFile. Originally, traffic.out was just a file whose file descriptor was dup2()’d from traffic_cop all the way to traffic_server (by way of fork()/exec()). With this patch, traffic_cop spawns the traffic_manager process with the location of traffic.out specified as flags (—-bind_stdout and -—bind_stderr). traffic_manager creates two BaseLogFile objects, one for each stdout and stderr, both mapped to traffic.out. traffic_manager then spawns the traffic_server process with the same flags, and traffic_server creates two BaseLogFiles in a similar fashion. As for the actual rotation, traffic_manager checks to see if traffic.out needs to be rotated once per iteration of traffic_manager’s main loop. As soon as traffic_manager rotates traffic.out, SIGUSR2 is sent from traffic_manager to traffic_server, and traffic_server catches SIGUSR2 and synchronizes its own BaseLogFiles with the newly created traffic.out file on disk. For rotation of diags.log, a continuation is scheduled every second in traffic_server to see if diags.log needs rotation, and then proceeds to rotate if necessary. manager.log is checked for rotation right after traffic.out is checked for rotation in the main loop of traffic_manager. enable log rotation for diags.log - Key: TS-306 URL: https://issues.apache.org/jira/browse/TS-306 Project: Traffic Server Issue Type: Improvement Components: Logging Reporter: Miles Libbey Assignee: Daniel Xu Labels: newbie Fix For: 6.1.0 (from yahoo bug 913896) Original description by Leif Hedstrom 3 years ago at 2006-12-04 12:42 There might be reasons why this file might get filled up, e.g. libraries used by plugins producing output on STDOUT/STDERR. A few suggestions have been made, to somehow rotate traffic.out. One possible solution (suggested by Ryan) is to use cronolog (http://cronolog.org/), which seems like a fine idea. Comment 1 by Joseph Rothrock 2 years ago at 2007-10-17 09:13:24 Maybe consider rolling diags.log as well. -Feature enhancement. Comment 2 by Kevin Dalley 13 months ago at 2009-03-04 15:32:18 When traffic.out gets filled up, error.log stops filing up, even though rotation is turned on. This is
[jira] [Commented] (TS-3777) TSHttpConnect and POST request does not fire TS_VCONN_READ_COMPLETE nor TS_VCONN_EOS
[
https://issues.apache.org/jira/browse/TS-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14662584#comment-14662584
]
Susan Hinrichs commented on TS-3777:
I've tracked this issue down to the HttpSM::tunnel_handler_ua() function. In
particular the part where it sets the half_close_flag if the event was write
complete and the request was a non-internal post or a pipeline_possible client.
If I comment out the ua_session-set_half_close_flag(), then Daniel's plugin
works properly. Otherwise, it stalls out in the post case (works in the get
case).
I'm not understanding the need for the logic, but I know there is a need. When
I removed the post check for TS-3640 [~sudheerv] found scenarios with large
memory leaks.
By setting the half_close flag, the following do_io_close only does a
shutdown_write on the client VC. Presumably this leaves the client VC around
to drain more post response. But if we did get a WRITE_COMPLETE it isn't clear
to me what post data remains to drain.
[~briang] and [~jacksontj] also made changes in this area for TS-3404 so
perhaps they could lend some guidance as well.
What is the memory leak caused by not doing the half_close_write for the post
on this case?
TSHttpConnect and POST request does not fire TS_VCONN_READ_COMPLETE nor
TS_VCONN_EOS
Key: TS-3777
URL: https://issues.apache.org/jira/browse/TS-3777
Project: Traffic Server
Issue Type: Bug
Components: TS API
Reporter: Daniel Vitor Morilha
Assignee: Susan Hinrichs
Labels: yahoo
Fix For: 6.1.0
When using TSHttpConnect to connect to ATS itself (internal vconnection),
sending a POST request and receiving a CHUNKED response. ATS does not fire
neither TS_VCONN_READ_COMPLETE nor TS_VCONN_EOS.
Trying to close the vconnection from the plug-in after receiving the last
chunk (\r\n0\r\n) results into the PluginVC repeating the following message:
{noformat}
[Jul 14 21:24:06.094] Server {0x77fbe800} DEBUG: (pvc_event) [0] Passive:
Received event 1
{noformat}
I am glad to provide an example if that helps.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-3821) Segmentation fault possibly due leaks in atscppapi
[
https://issues.apache.org/jira/browse/TS-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jiri Podhorsky updated TS-3821:
---
Attachment: EditHeader.cc
BlockIP.cc
AlwaysCache.cc
Segmentation fault possibly due leaks in atscppapi
--
Key: TS-3821
URL: https://issues.apache.org/jira/browse/TS-3821
Project: Traffic Server
Issue Type: Bug
Components: CPP API
Reporter: Jiri Podhorsky
Assignee: Brian Geffon
Fix For: 6.1.0
Attachments: AlwaysCache.cc, BlockIP.cc, EditHeader.cc
Hello,
I'm getting segmentation faults with ATS 5.3.1, possibly when I enabled
plugins in atscppapi, in which are used other Plugins than GlobalPlugin
(TransformationPlugin, InterceptionPlugin,...)
i'm building traffic server only with parameters:
./configure --prefix=/install --exec-prefix=/exec --with-user=trafficserver
--enable-cppapi
I'm getting segfault:
{noformat}
traffic_server: Segmentation fault (Address not mapped to object [(nil)])
traffic_server - STACK TRACE:
/www/trafficserver/install/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4c64d9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x2afbe25d90a0]
{noformat}
I tried to find an Issue and found possible leak in dectructor ~Transaction()
of Transaction.cc file.
The leak is, there is added plugin by addPlugin(TransactionPlugin *);
and according to documentation
[https://docs.trafficserver.apache.org/en/latest/api/classatscppapi_1_1Transaction.html#a9835e610553275d197cabfbd6d1cab7b],
Transaction should be responsible for cleaning.
But nothing removes items of list state_.plugins_, where should be pointers
to memory allocated with new, which won't be deleted by delete state_;
I tried to correct it with
{noformat}
for (TransactionPlugin* tmp : state_-plugins_) {
delete tmp;
}
{noformat}
But it didn't work. I'm getting similar segfault with another
{noformat}
traffic_server: Segmentation fault (Invalid permissions for mapped object
[0x2b86141ea898])
traffic_server - STACK TRACE:
/www/trafficserver/install/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4c64d9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x2b85d603d0a0]
[0x2b86141ea898]
{noformat}
I tried to find more deep and find the plugins should be freed by delete in
another class in file utils_internal.cc.
But if this is true, I should see in debug mode message, which is printed
before delete:
{noformat}
LOG_DEBUG(Locked Mutex...Deleting transaction plugin at %p, *iter);
{noformat}
But I don't see such messages in log.
I can see in error.log lot of these messages. I'm getting them at least every
second.
{noformat}
20150805.16h37m04s [atscppapi] [Transaction.cc:343, operator()()] server
request already initialized
{noformat}
Can you help me find the issue? Thanks for help in advance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3821) Segmentation fault possibly due leaks in atscppapi
[
https://issues.apache.org/jira/browse/TS-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661465#comment-14661465
]
Brian Geffon commented on TS-3821:
--
This crash is caused by a bug in your plugin code:
{code}
transaction.addPlugin(new
ResponseTransactionPlugin(transaction));
transaction.error();
return;
{code}
You're calling {{transaction.error()}} twice, once in the constructor of
{{ResponseTransactionPlugin()}} and once here. I'd suggest removing the
transaction.error() line from handleSendRequestHeaders.
Segmentation fault possibly due leaks in atscppapi
--
Key: TS-3821
URL: https://issues.apache.org/jira/browse/TS-3821
Project: Traffic Server
Issue Type: Bug
Components: CPP API
Reporter: Jiri Podhorsky
Assignee: Brian Geffon
Fix For: 6.1.0
Attachments: AlwaysCache.cc, BlockIP.cc, EditHeader.cc
Hello,
I'm getting segmentation faults with ATS 5.3.1, possibly when I enabled
plugins in atscppapi, in which are used other Plugins than GlobalPlugin
(TransformationPlugin, InterceptionPlugin,...)
i'm building traffic server only with parameters:
./configure --prefix=/install --exec-prefix=/exec --with-user=trafficserver
--enable-cppapi
I'm getting segfault:
{noformat}
traffic_server: Segmentation fault (Address not mapped to object [(nil)])
traffic_server - STACK TRACE:
/www/trafficserver/install/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4c64d9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x2afbe25d90a0]
{noformat}
I tried to find an Issue and found possible leak in dectructor ~Transaction()
of Transaction.cc file.
The leak is, there is added plugin by addPlugin(TransactionPlugin *);
and according to documentation
[https://docs.trafficserver.apache.org/en/latest/api/classatscppapi_1_1Transaction.html#a9835e610553275d197cabfbd6d1cab7b],
Transaction should be responsible for cleaning.
But nothing removes items of list state_.plugins_, where should be pointers
to memory allocated with new, which won't be deleted by delete state_;
I tried to correct it with
{noformat}
for (TransactionPlugin* tmp : state_-plugins_) {
delete tmp;
}
{noformat}
But it didn't work. I'm getting similar segfault with another
{noformat}
traffic_server: Segmentation fault (Invalid permissions for mapped object
[0x2b86141ea898])
traffic_server - STACK TRACE:
/www/trafficserver/install/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4c64d9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x2b85d603d0a0]
[0x2b86141ea898]
{noformat}
I tried to find more deep and find the plugins should be freed by delete in
another class in file utils_internal.cc.
But if this is true, I should see in debug mode message, which is printed
before delete:
{noformat}
LOG_DEBUG(Locked Mutex...Deleting transaction plugin at %p, *iter);
{noformat}
But I don't see such messages in log.
I can see in error.log lot of these messages. I'm getting them at least every
second.
{noformat}
20150805.16h37m04s [atscppapi] [Transaction.cc:343, operator()()] server
request already initialized
{noformat}
Can you help me find the issue? Thanks for help in advance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-3821) Segmentation fault possibly due leaks in atscppapi
[
https://issues.apache.org/jira/browse/TS-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661457#comment-14661457
]
Jiri Podhorsky commented on TS-3821:
I know it always make segfault. I'm not sure, if every backtrace of segfault
will be the same, but probably yes.
The segfault will happen, when I load the plugins and make benchmark
(downloading main pages) for a lot of web pages.
Yes, I will share some easy plugins. The others I use are using the same
function of traffic server and same libraries as these easy plugins.
Jiri
Segmentation fault possibly due leaks in atscppapi
--
Key: TS-3821
URL: https://issues.apache.org/jira/browse/TS-3821
Project: Traffic Server
Issue Type: Bug
Components: CPP API
Reporter: Jiri Podhorsky
Assignee: Brian Geffon
Fix For: 6.1.0
Hello,
I'm getting segmentation faults with ATS 5.3.1, possibly when I enabled
plugins in atscppapi, in which are used other Plugins than GlobalPlugin
(TransformationPlugin, InterceptionPlugin,...)
i'm building traffic server only with parameters:
./configure --prefix=/install --exec-prefix=/exec --with-user=trafficserver
--enable-cppapi
I'm getting segfault:
{noformat}
traffic_server: Segmentation fault (Address not mapped to object [(nil)])
traffic_server - STACK TRACE:
/www/trafficserver/install/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4c64d9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x2afbe25d90a0]
{noformat}
I tried to find an Issue and found possible leak in dectructor ~Transaction()
of Transaction.cc file.
The leak is, there is added plugin by addPlugin(TransactionPlugin *);
and according to documentation
[https://docs.trafficserver.apache.org/en/latest/api/classatscppapi_1_1Transaction.html#a9835e610553275d197cabfbd6d1cab7b],
Transaction should be responsible for cleaning.
But nothing removes items of list state_.plugins_, where should be pointers
to memory allocated with new, which won't be deleted by delete state_;
I tried to correct it with
{noformat}
for (TransactionPlugin* tmp : state_-plugins_) {
delete tmp;
}
{noformat}
But it didn't work. I'm getting similar segfault with another
{noformat}
traffic_server: Segmentation fault (Invalid permissions for mapped object
[0x2b86141ea898])
traffic_server - STACK TRACE:
/www/trafficserver/install/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4c64d9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x2b85d603d0a0]
[0x2b86141ea898]
{noformat}
I tried to find more deep and find the plugins should be freed by delete in
another class in file utils_internal.cc.
But if this is true, I should see in debug mode message, which is printed
before delete:
{noformat}
LOG_DEBUG(Locked Mutex...Deleting transaction plugin at %p, *iter);
{noformat}
But I don't see such messages in log.
I can see in error.log lot of these messages. I'm getting them at least every
second.
{noformat}
20150805.16h37m04s [atscppapi] [Transaction.cc:343, operator()()] server
request already initialized
{noformat}
Can you help me find the issue? Thanks for help in advance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Jenkins build is still unstable: tsqa-lint #422
See https://ci.trafficserver.apache.org/job/tsqa-lint/changes
Jenkins build is still unstable: tsqa-lint #423
See https://ci.trafficserver.apache.org/job/tsqa-lint/changes
[jira] [Updated] (TS-3830) Metrics created via stats.config.xml should not need to be registered in RecordsConfig.cc
[ https://issues.apache.org/jira/browse/TS-3830?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-3830: -- Fix Version/s: 6.1.0 Metrics created via stats.config.xml should not need to be registered in RecordsConfig.cc - Key: TS-3830 URL: https://issues.apache.org/jira/browse/TS-3830 Project: Traffic Server Issue Type: Bug Components: Metrics Reporter: Leif Hedstrom Fix For: 6.1.0 It seems superfluous, and very inflexible, to require the calculated metrics in stats.config.xml to also need to be registered in RecordsConfig.cc. I think that should just be automatic, leaving RecordsConfig.cc with only configurations. If there are metrics in RecordsConfig.cc which are not calculated via stats.config.xml, they should be registered in other submodules, like we generally do for everything else. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3830) Metrics created via stats.config.xml should not need to be registered in RecordsConfig.cc
Leif Hedstrom created TS-3830: - Summary: Metrics created via stats.config.xml should not need to be registered in RecordsConfig.cc Key: TS-3830 URL: https://issues.apache.org/jira/browse/TS-3830 Project: Traffic Server Issue Type: Bug Components: Metrics Reporter: Leif Hedstrom It seems superfluous, and very inflexible, to require the calculated metrics in stats.config.xml to also need to be registered in RecordsConfig.cc. I think that should just be automatic, leaving RecordsConfig.cc with only configurations. If there are metrics in RecordsConfig.cc which are not calculated via stats.config.xml, they should be registered in other submodules, like we generally do for everything else. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-1980) Provide API for a plugin to also specify which body factory template to use for errors
[
https://issues.apache.org/jira/browse/TS-1980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alan M. Carroll updated TS-1980:
Assignee: Syeda Persia Aziz
Provide API for a plugin to also specify which body factory template to use
for errors
--
Key: TS-1980
URL: https://issues.apache.org/jira/browse/TS-1980
Project: Traffic Server
Issue Type: New Feature
Components: TS API
Reporter: Leif Hedstrom
Assignee: Syeda Persia Aziz
Fix For: sometime
Right now, there are only two APIs that allows plugins to set the HTTP status
code and body message:
{code}
tsapi void TSHttpTxnSetHttpRetBody(TSHttpTxn txnp, const char* body_msg,
int plain_msg);
tsapi void TSHttpTxnSetHttpRetStatus(TSHttpTxn txnp, TSHttpStatus
http_retstatus);
{code}
Since the body factory (templates) are now the only way to produce error
messages from within ATS itself, these APIs are now lacking a way to specify
which template to use. I imagine three possibilities (at least):
1) Make the last argument to TSHttpTxnSetHttpRetBody() be a multi-value
variable, with the semantics of
0 - body is HTML
1 - body is plain text
2 - body is a factory template name (e.g. access#denied or shrek#ogre).
This is probably pretty safe, but perhaps not super pretty.
2) Make TSHttpTxnSetHttpRetStatus() also take a body factory argument, e.g.
{code}
tsapi void TSHttpTxnSetHttpRetStatus(TSHttpTxn txnp, TSHttpStatus
http_retstatus, const char* factory);
{code}
factory should probably be a string here, and not constants, because users
can put in arbitrary file names into the body factory. The string really is
the filename. This would break compatibility of the APIs I think.
3) We add a new API, e.g.
{code}
tsapi void TSHttpTxnSetHttpFactory(TSHttpTxn txnp, const char* factory);
{code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
Build failed in Jenkins: tsqa-master #773
See https://ci.trafficserver.apache.org/job/tsqa-master/773/changes
Changes:
[James Peach] Enable automake maintainer mode.
--
Started by upstream project out_of_tree-master build number 1075
originally caused by:
Started by an SCM change
Started by upstream project in_tree-master build number 1294
originally caused by:
Started by an SCM change
Building remotely on QA3 (qa) in workspace
https://ci.trafficserver.apache.org/job/tsqa-master/ws/
/usr/bin/git rev-parse --is-inside-work-tree # timeout=10
Fetching changes from the remote Git repository
/usr/bin/git config remote.origin.url
https://git-wip-us.apache.org/repos/asf/trafficserver.git # timeout=10
Cleaning workspace
/usr/bin/git rev-parse --verify HEAD # timeout=10
Resetting working tree
/usr/bin/git reset --hard # timeout=10
/usr/bin/git clean -fdx # timeout=10
Fetching upstream changes from
https://git-wip-us.apache.org/repos/asf/trafficserver.git
/usr/bin/git --version # timeout=10
/usr/bin/git -c core.askpass=true fetch --tags --progress
https://git-wip-us.apache.org/repos/asf/trafficserver.git
+refs/heads/*:refs/remotes/origin/*
/usr/bin/git rev-parse refs/remotes/origin/master^{commit} # timeout=10
/usr/bin/git rev-parse refs/remotes/origin/origin/master^{commit} #
timeout=10
Checking out Revision d903a38d169e8b43c51fce001afab5da81e4b754
(refs/remotes/origin/master)
/usr/bin/git config core.sparsecheckout # timeout=10
/usr/bin/git checkout -f d903a38d169e8b43c51fce001afab5da81e4b754
/usr/bin/git rev-list 2f154297a749bc9da54ce4373ef7198dcd75fb02 # timeout=10
[tsqa-master] $ /bin/bash -xe /tmp/hudson6660628410640333799.sh
+ source /home/jenkins/bin/environment.sh
++ export ATS_SRC_HOME=/home/jenkins/src
++ ATS_SRC_HOME=/home/jenkins/src
++ test tsqa-master '!=' tsqa-master
++ ATS_MAKE=make
++ test tsqa-master '!=' tsqa-master
++ export ATS_MAKE
+++ /bin/date +%m%d%Y
++ export TODAY=08072015
++ TODAY=08072015
++ ATS_BRANCH=master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ test tsqa-master '!=' tsqa-master
++ export ATS_BRANCH
++ test tsqa-master '!=' tsqa-master
+ source /home/jenkins/bin/tsqa.sh
++ TSQA_LAYOUT_DIR=https://ci.trafficserver.apache.org/job/tsqa-master/ws/773
++ cd https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa
++ make test
New python executable in virtualenv/bin/python
Installing
Setuptools..done.
Installing
Pip.done.
make update
make[1]: Entering directory
`https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa'
Exception:
Traceback (most recent call last):
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pip/basecommand.py;,
line 134, in main
status = self.run(options, args)
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pip/commands/install.py;,
line 220, in run
for req in parse_requirements(filename, finder=finder, options=options):
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pip/req.py;,
line 1477, in parse_requirements
req = InstallRequirement.from_line(line, comes_from,
prereleases=getattr(options, pre, None))
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pip/req.py;,
line 129, in from_line
return cls(req, comes_from, url=url, prereleases=prereleases)
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pip/req.py;,
line 44, in __init__
req = pkg_resources.Requirement.parse(req)
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pkg_resources.py;,
line 2914, in parse
reqs = list(parse_requirements(s))
File
https://ci.trafficserver.apache.org/job/tsqa-master/ws/src/ci/tsqa/virtualenv/lib/python2.7/site-packages/pkg_resources.py;,
line 2839, in
[jira] [Updated] (TS-3831) Overridable error response type
[ https://issues.apache.org/jira/browse/TS-3831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Syeda Persia Aziz updated TS-3831: -- Description: ATS has a set of error pages in the folder body_factory, namely access#denied, access#proxy_auth_required,connect#dns_failed... etc. All these error pages are loaded in a RawHashTable. When there is an error for e.g. access denied, ATS builds a error response of type access#denied. We can have an overridable config that will decide which custom error page to send to the client. This config will be set per remap rule. We can have the custom error pages in the body_factory folder and these pages will follow a specific naming convention for e.g. $var_access#denied, $var_proxy_auth_required, ….. Here $var is the overridable config (proxy.config.error.response.type). Example: in Remap.config map www.abcxyz.com www.efgijk.com @plugin=config.so @pparam=proxy.config.error.response.type=yahoo Now, if there is for e.g. a 'access denied' error, the build_error_response will build a customized error response of type yahoo_access#denied . If it can not find the type yahoo_access#denied, then it will simply build the default access#denied error response. Note: I already have a patch for this. I am thinking of test cases. was: ATS has a set of error pages in the folder body_factory, namely access#denied.html, access#proxy_auth_required.html,connect#dns_failed.html... etc. All these error pages are loaded in a RawHashTable. When there is an error for e.g. access denied, ATS builds a error response of type access#denied. We can have an overridable config that will decide which custom error page to send to the client. This config will be set per remap rule. We can have the custom error pages in the body_factory folder and these pages will follow a specific naming convention for e.g. $var_access#denied.html, $var_proxy_auth_required.html, ….. Here $var is the overridable config (proxy.config.error.response.type). Example: in Remap.config map www.abcxyz.com www.efgijk.com @plugin=config.so @pparam=proxy.config.error.response.type=yahoo Now, if there is for e.g. a 'access denied' error, the build_error_response will build a customized error response of type yahoo_access#denied . If it can not find the type yahoo_access#denied, then it will simply build the default access#denied error response. Note: I already have a patch for this. I am thinking of test cases. Overridable error response type --- Key: TS-3831 URL: https://issues.apache.org/jira/browse/TS-3831 Project: Traffic Server Issue Type: New Feature Components: Configuration Reporter: Syeda Persia Aziz ATS has a set of error pages in the folder body_factory, namely access#denied, access#proxy_auth_required,connect#dns_failed... etc. All these error pages are loaded in a RawHashTable. When there is an error for e.g. access denied, ATS builds a error response of type access#denied. We can have an overridable config that will decide which custom error page to send to the client. This config will be set per remap rule. We can have the custom error pages in the body_factory folder and these pages will follow a specific naming convention for e.g. $var_access#denied, $var_proxy_auth_required, ….. Here $var is the overridable config (proxy.config.error.response.type). Example: in Remap.config map www.abcxyz.com www.efgijk.com @plugin=config.so @pparam=proxy.config.error.response.type=yahoo Now, if there is for e.g. a 'access denied' error, the build_error_response will build a customized error response of type yahoo_access#denied . If it can not find the type yahoo_access#denied, then it will simply build the default access#denied error response. Note: I already have a patch for this. I am thinking of test cases. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (TS-3831) Overridable error response type
[ https://issues.apache.org/jira/browse/TS-3831?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Syeda Persia Aziz updated TS-3831: -- Description: ATS has a set of error pages in the folder body_factory, namely access#denied, access#proxy_auth_required,connect#dns_failed... etc. All these error pages are loaded in a RawHashTable. When there is an error for e.g. access denied, ATS builds a error response of type access#denied. We can have an overridable config that will decide which custom error page to send to the client. This config will be set per remap rule. We can have the custom error pages in the body_factory folder and these pages will follow a specific naming convention for e.g. $var_access#denied, $var_proxy_auth_required, ….. Here $var is the overridable config (proxy.config.error.response.type). Example: in Remap.config map www.abcxyz.com www.efgijk.com @plugin=config.so @pparam=proxy.config.error.response.type=yahoo Now, if there is for e.g. a 'access denied' error, the build_error_response will build a customized error response of type yahoo_access#denied . If it can not find the type yahoo_access#denied, then it will simply build the default access#denied error response. Note: I already have a patch for this. was: ATS has a set of error pages in the folder body_factory, namely access#denied, access#proxy_auth_required,connect#dns_failed... etc. All these error pages are loaded in a RawHashTable. When there is an error for e.g. access denied, ATS builds a error response of type access#denied. We can have an overridable config that will decide which custom error page to send to the client. This config will be set per remap rule. We can have the custom error pages in the body_factory folder and these pages will follow a specific naming convention for e.g. $var_access#denied, $var_proxy_auth_required, ….. Here $var is the overridable config (proxy.config.error.response.type). Example: in Remap.config map www.abcxyz.com www.efgijk.com @plugin=config.so @pparam=proxy.config.error.response.type=yahoo Now, if there is for e.g. a 'access denied' error, the build_error_response will build a customized error response of type yahoo_access#denied . If it can not find the type yahoo_access#denied, then it will simply build the default access#denied error response. Note: I already have a patch for this. I am thinking of test cases. Overridable error response type --- Key: TS-3831 URL: https://issues.apache.org/jira/browse/TS-3831 Project: Traffic Server Issue Type: New Feature Components: Configuration Reporter: Syeda Persia Aziz ATS has a set of error pages in the folder body_factory, namely access#denied, access#proxy_auth_required,connect#dns_failed... etc. All these error pages are loaded in a RawHashTable. When there is an error for e.g. access denied, ATS builds a error response of type access#denied. We can have an overridable config that will decide which custom error page to send to the client. This config will be set per remap rule. We can have the custom error pages in the body_factory folder and these pages will follow a specific naming convention for e.g. $var_access#denied, $var_proxy_auth_required, ….. Here $var is the overridable config (proxy.config.error.response.type). Example: in Remap.config map www.abcxyz.com www.efgijk.com @plugin=config.so @pparam=proxy.config.error.response.type=yahoo Now, if there is for e.g. a 'access denied' error, the build_error_response will build a customized error response of type yahoo_access#denied . If it can not find the type yahoo_access#denied, then it will simply build the default access#denied error response. Note: I already have a patch for this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (TS-3831) Overridable error response type
Syeda Persia Aziz created TS-3831: - Summary: Overridable error response type Key: TS-3831 URL: https://issues.apache.org/jira/browse/TS-3831 Project: Traffic Server Issue Type: New Feature Components: Configuration Reporter: Syeda Persia Aziz ATS has a set of error pages in the folder body_factory, namely access#denied.html, access#proxy_auth_required.html,connect#dns_failed.html... etc. All these error pages are loaded in a RawHashTable. When there is an error for e.g. access denied, ATS builds a error response of type access#denied. We can have an overridable config that will decide which custom error page to send to the client. This config will be set per remap rule. We can have the custom error pages in the body_factory folder and these pages will follow a specific naming convention for e.g. $var_access#denied.html, $var_proxy_auth_required.html, ….. Here $var is the overridable config (proxy.config.error.response.type). Example: in Remap.config map www.abcxyz.com www.efgijk.com @plugin=config.so @pparam=proxy.config.error.response.type=yahoo Now, if there is for e.g. a 'access denied' error, the build_error_response will build a customized error response of type yahoo_access#denied . If it can not find the type yahoo_access#denied, then it will simply build the default access#denied error response. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-3821) Segmentation fault possibly due leaks in atscppapi
[
https://issues.apache.org/jira/browse/TS-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14661754#comment-14661754
]
Jiri Podhorsky commented on TS-3821:
Oh, thanks. I miss that. I will fix the issue and run benchmark again to prove
if the issue is still reproducible.
Segmentation fault possibly due leaks in atscppapi
--
Key: TS-3821
URL: https://issues.apache.org/jira/browse/TS-3821
Project: Traffic Server
Issue Type: Bug
Components: CPP API
Reporter: Jiri Podhorsky
Assignee: Brian Geffon
Fix For: 6.1.0
Attachments: AlwaysCache.cc, BlockIP.cc, EditHeader.cc
Hello,
I'm getting segmentation faults with ATS 5.3.1, possibly when I enabled
plugins in atscppapi, in which are used other Plugins than GlobalPlugin
(TransformationPlugin, InterceptionPlugin,...)
i'm building traffic server only with parameters:
./configure --prefix=/install --exec-prefix=/exec --with-user=trafficserver
--enable-cppapi
I'm getting segfault:
{noformat}
traffic_server: Segmentation fault (Address not mapped to object [(nil)])
traffic_server - STACK TRACE:
/www/trafficserver/install/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4c64d9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x2afbe25d90a0]
{noformat}
I tried to find an Issue and found possible leak in dectructor ~Transaction()
of Transaction.cc file.
The leak is, there is added plugin by addPlugin(TransactionPlugin *);
and according to documentation
[https://docs.trafficserver.apache.org/en/latest/api/classatscppapi_1_1Transaction.html#a9835e610553275d197cabfbd6d1cab7b],
Transaction should be responsible for cleaning.
But nothing removes items of list state_.plugins_, where should be pointers
to memory allocated with new, which won't be deleted by delete state_;
I tried to correct it with
{noformat}
for (TransactionPlugin* tmp : state_-plugins_) {
delete tmp;
}
{noformat}
But it didn't work. I'm getting similar segfault with another
{noformat}
traffic_server: Segmentation fault (Invalid permissions for mapped object
[0x2b86141ea898])
traffic_server - STACK TRACE:
/www/trafficserver/install/bin/traffic_server(_Z19crash_logger_invokeiP7siginfoPv+0x99)[0x4c64d9]
/lib/x86_64-linux-gnu/libpthread.so.0(+0xf0a0)[0x2b85d603d0a0]
[0x2b86141ea898]
{noformat}
I tried to find more deep and find the plugins should be freed by delete in
another class in file utils_internal.cc.
But if this is true, I should see in debug mode message, which is printed
before delete:
{noformat}
LOG_DEBUG(Locked Mutex...Deleting transaction plugin at %p, *iter);
{noformat}
But I don't see such messages in log.
I can see in error.log lot of these messages. I'm getting them at least every
second.
{noformat}
20150805.16h37m04s [atscppapi] [Transaction.cc:343, operator()()] server
request already initialized
{noformat}
Can you help me find the issue? Thanks for help in advance.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
