[jira] [Work logged] (TS-5050) The background_fetch plugin fails to check for config files relative to the config dir etc/trafficserver
[
https://issues.apache.org/jira/browse/TS-5050?focusedWorklogId=32062&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-32062
]
ASF GitHub Bot logged work on TS-5050:
--
Author: ASF GitHub Bot
Created on: 15/Nov/16 05:01
Start Date: 15/Nov/16 05:01
Worklog Time Spent: 10m
Work Description: Github user jpeach commented on a diff in the pull
request:
https://github.com/apache/trafficserver/pull/1218#discussion_r87948595
--- Diff: plugins/background_fetch/configs.cc ---
@@ -44,8 +44,13 @@ BgFetchConfig::readConfig(const char *config_file)
snprintf(file_path, sizeof(file_path), "%s/%s", TSInstallDirGet(),
config_file);
file = TSfopen(file_path, "r");
if (nullptr == file) {
- TSError("[%s] invalid config file", PLUGIN_NAME);
- return false;
+ TSDebug(PLUGIN_NAME, "Failed to open config file %s, trying config
path", config_file);
+ snprintf(file_path, sizeof(file_path), "%s/%s", TSConfigDirGet(),
config_file);
+ file = TSfopen(file_path, "r");
+ if (NULL == file) {
+TSError("[%s] invalid config file", PLUGIN_NAME);
+return false;
+ }
--- End diff --
This should be:
```C
if (*config_file == '/') {
file = TSfopen(config_file, "r");
} else {
file = path.join(TSConfigDirGet(), config_file);
}
```
By trying the given path without qualification you allow operators to
accidentally depend on the current working directory. The pseudocode above is
what all the other plugins do, and I think that it is worth being consistent
with this.
Issue Time Tracking
---
Worklog Id: (was: 32062)
Time Spent: 1.5h (was: 1h 20m)
> The background_fetch plugin fails to check for config files relative to the
> config dir etc/trafficserver
>
>
> Key: TS-5050
> URL: https://issues.apache.org/jira/browse/TS-5050
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Affects Versions: 6.2.0, 7.0.0, 7.1.0
>Reporter: John Rushford
>Assignee: John Rushford
> Fix For: 7.1.0
>
> Time Spent: 1.5h
> Remaining Estimate: 0h
>
> We are currently using the background_fetch plugin with ATS 5.3.2 per remap.
> We configure the background_fetch plugin in remap.config using the relative
> path to a config file in etc/trafficserver. While testing ATS 6.2.1 with our
> configs, I found that the background_fetch plugin no-longer looks for config
> files relative to the etc/trafficserver configuration directory.
> I think that this is a regression from 5.3.2 to 6.2.x and master. I found
> that in configs.cc, TSConfigDirGet() is no-longer used to check for a config
> file relative to etc/trafficserver.
> I'm testing a patch to fix this.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver pull request #1218: TS-5050: The background_fetch plugin fails...
Github user jpeach commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/1218#discussion_r87948595
--- Diff: plugins/background_fetch/configs.cc ---
@@ -44,8 +44,13 @@ BgFetchConfig::readConfig(const char *config_file)
snprintf(file_path, sizeof(file_path), "%s/%s", TSInstallDirGet(),
config_file);
file = TSfopen(file_path, "r");
if (nullptr == file) {
- TSError("[%s] invalid config file", PLUGIN_NAME);
- return false;
+ TSDebug(PLUGIN_NAME, "Failed to open config file %s, trying config
path", config_file);
+ snprintf(file_path, sizeof(file_path), "%s/%s", TSConfigDirGet(),
config_file);
+ file = TSfopen(file_path, "r");
+ if (NULL == file) {
+TSError("[%s] invalid config file", PLUGIN_NAME);
+return false;
+ }
--- End diff --
This should be:
```C
if (*config_file == '/') {
file = TSfopen(config_file, "r");
} else {
file = path.join(TSConfigDirGet(), config_file);
}
```
By trying the given path without qualification you allow operators to
accidentally depend on the current working directory. The pseudocode above is
what all the other plugins do, and I think that it is worth being consistent
with 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.
---
[jira] [Created] (TS-5054) url_sig plugin loads configuration inconsistently
James Peach created TS-5054:
---
Summary: url_sig plugin loads configuration inconsistently
Key: TS-5054
URL: https://issues.apache.org/jira/browse/TS-5054
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: James Peach
{noformat}
const char *install_dir = TSInstallDirGet();
snprintf(config_file, sizeof(config_file), "%s/%s/%s", install_dir,
"etc/trafficserver", argv[2]);
TSDebug(PLUGIN_NAME, "config file name: %s", config_file);
FILE *file = fopen(config_file, "r");
if (file == NULL) {
snprintf(errbuf, errbuf_size - 1, "[TSRemapNewInstance] - Error opening
file %s.", config_file);
return TS_ERROR;
}
{noformat}
The policy for plugins is to load absolute paths if specified, then treat is as
a path relative to {{TSConfigDirGet}}.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5046) SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p)
[
https://issues.apache.org/jira/browse/TS-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masa Sekimura updated TS-5046:
--
Assignee: Susan Hinrichs
> SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p)
> -
>
> Key: TS-5046
> URL: https://issues.apache.org/jira/browse/TS-5046
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, Network
>Reporter: Masa Sekimura
>Assignee: Susan Hinrichs
> Fix For: 6.2.1
>
>
> one of servers running 6.2.x (729c60b) got a SIGSEGV
> {code}
> (gdb) thread 42
> [Switching to thread 42 (Thread 0x2aaab460d700 (LWP 4145))]
> #0 0x2d6bd37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> 41../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
> (gdb) bt
> #0 0x2d6bd37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> #1 0x2ab81ec7 in crash_logger_invoke (signo=11, info=0x2aaab460bcf0,
> ctx=0x2aaab460bbc0) at Crash.cc:164
> #2
> #3 0x2ac83358 in HttpSM::tunnel_handler_server (this=0x2ab9b4efac00,
> event=, p=) at HttpSM.cc:3108
> #4 0x2ace1d72 in HttpTunnel::producer_handler
> (this=this@entry=0x2ab9b4efbf28, event=102, event@entry=100,
> p=p@entry=0x2ab9b4efc128) at HttpTunnel.cc:1240
> #5 0x2ace3343 in HttpTunnel::producer_run
> (this=this@entry=0x2ab9b4efbf28, p=p@entry=0x2ab9b4efc128) at
> HttpTunnel.cc:1020
> #6 0x2ace3d71 in HttpTunnel::tunnel_run (this=0x2ab9b4efbf28,
> p_arg=0x2ab9b4efc128) at HttpTunnel.cc:787
> #7 0x2ac96f8b in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1534
> #8 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #9 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #10 0x2aaabe845c05 in XInjectResponseHeaders (event=,
> edata=0x2ab9b4efac00) at xdebug.cc:295
> #11 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9dc0,
> event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #12 0x2ac96d10 in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1452
> #13 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #14 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #15 0x2aaabe01ea45 in cont_rewrite_headers (contp=0x2aaab6bf9ee0,
> event=, edata=0x2ab9b4efac00) at header_rewrite.cc:307
> #16 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9ee0,
> event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #17 0x2ac96d10 in HttpSM::state_api_callout (this=0x2ab9b4efac00,
> event=, data=) at HttpSM.cc:1452
> #18 0x2ac9c910 in HttpSM::set_next_state (this=0x2ab9b4efac00) at
> HttpSM.cc:7296
> #19 0x2ac96f8b in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1534
> #20 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #21 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #22 0x2aaabf4038d5 in cont_handle_response (contp=,
> event=, edata=0x2ab9b4efac00) at background_fetch.cc:544
> #23 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9d00,
> event=60006, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #24 0x2ac96d10 in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1452
> #25 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #26 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #27 0x2aaabe01ea45 in cont_rewrite_headers (contp=0x2aaab6bf9ee0,
> event=, edata=0x2ab9b4efac00) at header_rewrite.cc:307
> #28 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9ee0,
> event=60006, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #29 0x2ac96d10 in HttpSM::state_api_callout (this=0x2ab9b4efac00,
> event=, data=) at HttpSM.cc:1452
> #30 0x2ac97b6f in HttpSM::state_read_server_response_header
> (this=0x2ab9b4efac00, event=100, data
[jira] [Commented] (TS-5046) SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p)
[
https://issues.apache.org/jira/browse/TS-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15665585#comment-15665585
]
Masa Sekimura commented on TS-5046:
---
There must be a proper way to fix this issue in 7.0.x branch already but here's
a bandaid I might want to try.
{code}
diff --git a/proxy/http/HttpSM.cc b/proxy/http/HttpSM.cc
index b7a1be2..9344873 100644
--- a/proxy/http/HttpSM.cc
+++ b/proxy/http/HttpSM.cc
@@ -3105,7 +3105,10 @@ HttpSM::tunnel_handler_server(int event,
HttpTunnelProducer *p)
ua_session->attach_server_session(server_session);
} else {
// Release the session back into the shared session pool
-
server_session->get_netvc()->set_inactivity_timeout(HRTIME_SECONDS(t_state.txn_conf->keep_alive_no_activity_timeout_out));
+ NetVConnection *vc = server_session->get_netvc();
+ if (vc) {
+
vc->set_inactivity_timeout(HRTIME_SECONDS(t_state.txn_conf->keep_alive_no_activity_timeout_out));
+ }
server_session->release();
}
}
{code}
> SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p)
> -
>
> Key: TS-5046
> URL: https://issues.apache.org/jira/browse/TS-5046
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP, Network
>Reporter: Masa Sekimura
> Fix For: 6.2.1
>
>
> one of servers running 6.2.x (729c60b) got a SIGSEGV
> {code}
> (gdb) thread 42
> [Switching to thread 42 (Thread 0x2aaab460d700 (LWP 4145))]
> #0 0x2d6bd37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> 41../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
> (gdb) bt
> #0 0x2d6bd37d in __libc_waitpid (pid=,
> stat_loc=, options=) at
> ../sysdeps/unix/sysv/linux/waitpid.c:41
> #1 0x2ab81ec7 in crash_logger_invoke (signo=11, info=0x2aaab460bcf0,
> ctx=0x2aaab460bbc0) at Crash.cc:164
> #2
> #3 0x2ac83358 in HttpSM::tunnel_handler_server (this=0x2ab9b4efac00,
> event=, p=) at HttpSM.cc:3108
> #4 0x2ace1d72 in HttpTunnel::producer_handler
> (this=this@entry=0x2ab9b4efbf28, event=102, event@entry=100,
> p=p@entry=0x2ab9b4efc128) at HttpTunnel.cc:1240
> #5 0x2ace3343 in HttpTunnel::producer_run
> (this=this@entry=0x2ab9b4efbf28, p=p@entry=0x2ab9b4efc128) at
> HttpTunnel.cc:1020
> #6 0x2ace3d71 in HttpTunnel::tunnel_run (this=0x2ab9b4efbf28,
> p_arg=0x2ab9b4efc128) at HttpTunnel.cc:787
> #7 0x2ac96f8b in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1534
> #8 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #9 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #10 0x2aaabe845c05 in XInjectResponseHeaders (event=,
> edata=0x2ab9b4efac00) at xdebug.cc:295
> #11 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9dc0,
> event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #12 0x2ac96d10 in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1452
> #13 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #14 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #15 0x2aaabe01ea45 in cont_rewrite_headers (contp=0x2aaab6bf9ee0,
> event=, edata=0x2ab9b4efac00) at header_rewrite.cc:307
> #16 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9ee0,
> event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #17 0x2ac96d10 in HttpSM::state_api_callout (this=0x2ab9b4efac00,
> event=, data=) at HttpSM.cc:1452
> #18 0x2ac9c910 in HttpSM::set_next_state (this=0x2ab9b4efac00) at
> HttpSM.cc:7296
> #19 0x2ac96f8b in HttpSM::state_api_callout
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1534
> #20 0x2ac9e0d3 in HttpSM::state_api_callback
> (this=this@entry=0x2ab9b4efac00, event=event@entry=6,
> data=data@entry=0x0) at HttpSM.cc:1331
> #21 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
> event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
> #22 0x2aaabf4038d5 in cont_handle_response (contp=,
> event=, edata=0x2ab9b4efac00) at background_fetch.cc:544
> #23 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9d00,
> event=60006, edata=0x2ab9b4efac00) at InkAPI.cc:1006
> #24 0x2ac96d10 in HttpSM::state_api_callout
> (this=this@ent
[jira] [Updated] (TS-5046) SEGV HttpSM::tunnel_handler_server(int event, HttpTunnelProducer *p)
[
https://issues.apache.org/jira/browse/TS-5046?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Masa Sekimura updated TS-5046:
--
Description:
one of servers running 6.2.x (729c60b) got a SIGSEGV
{code}
(gdb) thread 42
[Switching to thread 42 (Thread 0x2aaab460d700 (LWP 4145))]
#0 0x2d6bd37d in __libc_waitpid (pid=,
stat_loc=, options=) at
../sysdeps/unix/sysv/linux/waitpid.c:41
41 ../sysdeps/unix/sysv/linux/waitpid.c: No such file or directory.
(gdb) bt
#0 0x2d6bd37d in __libc_waitpid (pid=,
stat_loc=, options=) at
../sysdeps/unix/sysv/linux/waitpid.c:41
#1 0x2ab81ec7 in crash_logger_invoke (signo=11, info=0x2aaab460bcf0,
ctx=0x2aaab460bbc0) at Crash.cc:164
#2
#3 0x2ac83358 in HttpSM::tunnel_handler_server (this=0x2ab9b4efac00,
event=, p=) at HttpSM.cc:3108
#4 0x2ace1d72 in HttpTunnel::producer_handler
(this=this@entry=0x2ab9b4efbf28, event=102, event@entry=100,
p=p@entry=0x2ab9b4efc128) at HttpTunnel.cc:1240
#5 0x2ace3343 in HttpTunnel::producer_run
(this=this@entry=0x2ab9b4efbf28, p=p@entry=0x2ab9b4efc128) at HttpTunnel.cc:1020
#6 0x2ace3d71 in HttpTunnel::tunnel_run (this=0x2ab9b4efbf28,
p_arg=0x2ab9b4efc128) at HttpTunnel.cc:787
#7 0x2ac96f8b in HttpSM::state_api_callout
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1534
#8 0x2ac9e0d3 in HttpSM::state_api_callback
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1331
#9 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
#10 0x2aaabe845c05 in XInjectResponseHeaders (event=,
edata=0x2ab9b4efac00) at xdebug.cc:295
#11 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9dc0,
event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
#12 0x2ac96d10 in HttpSM::state_api_callout
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1452
#13 0x2ac9e0d3 in HttpSM::state_api_callback
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1331
#14 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
#15 0x2aaabe01ea45 in cont_rewrite_headers (contp=0x2aaab6bf9ee0,
event=, edata=0x2ab9b4efac00) at header_rewrite.cc:307
#16 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9ee0,
event=60007, edata=0x2ab9b4efac00) at InkAPI.cc:1006
#17 0x2ac96d10 in HttpSM::state_api_callout (this=0x2ab9b4efac00,
event=, data=) at HttpSM.cc:1452
#18 0x2ac9c910 in HttpSM::set_next_state (this=0x2ab9b4efac00) at
HttpSM.cc:7296
#19 0x2ac96f8b in HttpSM::state_api_callout
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1534
#20 0x2ac9e0d3 in HttpSM::state_api_callback
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1331
#21 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
#22 0x2aaabf4038d5 in cont_handle_response (contp=,
event=, edata=0x2ab9b4efac00) at background_fetch.cc:544
#23 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9d00,
event=60006, edata=0x2ab9b4efac00) at InkAPI.cc:1006
#24 0x2ac96d10 in HttpSM::state_api_callout
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1452
#25 0x2ac9e0d3 in HttpSM::state_api_callback
(this=this@entry=0x2ab9b4efac00, event=event@entry=6, data=data@entry=0x0)
at HttpSM.cc:1331
#26 0x2abad6ad in TSHttpTxnReenable (txnp=0x2ab9b4efac00,
event=TS_EVENT_HTTP_CONTINUE) at InkAPI.cc:5652
#27 0x2aaabe01ea45 in cont_rewrite_headers (contp=0x2aaab6bf9ee0,
event=, edata=0x2ab9b4efac00) at header_rewrite.cc:307
#28 0x2ab98c04 in INKContInternal::handle_event (this=0x2aaab6bf9ee0,
event=60006, edata=0x2ab9b4efac00) at InkAPI.cc:1006
#29 0x2ac96d10 in HttpSM::state_api_callout (this=0x2ab9b4efac00,
event=, data=) at HttpSM.cc:1452
#30 0x2ac97b6f in HttpSM::state_read_server_response_header
(this=0x2ab9b4efac00, event=100, data=0x2aaaf59b3a98) at HttpSM.cc:1953
#31 0x2ac9e2bd in HttpSM::main_handler (this=0x2ab9b4efac00, event=100,
data=0x2aaaf59b3a98) at HttpSM.cc:2658
#32 0x2ae6956b in Continuation::handleEvent (data=0x2aaaf59b3a98,
event=100, this=) at
../../iocore/eventsystem/I_Continuation.h:153
#33 read_signal_and_update (vc=0x2aaaf59b3980, vc@entry=0x1,
event=event@entry=100) at UnixNetVConnection.cc:148
#34 UnixNetVConnection::readSignalAndUpdate (this=this@entry=0x2aaaf59b3980,
event=event@entry=100) at UnixNetVConnection.cc:1030
#35 0x2ae48cb3 in SSLNetVConnection::net_read_io (this=0x2aaaf59b3980,
nh=0x
[jira] [Commented] (TS-5053) const char **argv passed to TSPluginInit is not null terminated
[
https://issues.apache.org/jira/browse/TS-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15664549#comment-15664549
]
James Peach commented on TS-5053:
-
Seems reasonable to fix this, but plugins must not use {{ink_args.cc}}. It's
not a plugin API.
> const char **argv passed to TSPluginInit is not null terminated
> ---
>
> Key: TS-5053
> URL: https://issues.apache.org/jira/browse/TS-5053
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> See title. Typically **argv is null terminated in other systems. And who are
> we to question 1000 years of tradition?
> One example of an issue is that {{lib/ts/ink_args.cc}} actually relies on
> **argv being null terminated. Interesting segfaults occur in plugins usings
> the ATS argument parser.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5053) const char **argv passed to TSPluginInit is not null terminated
[
https://issues.apache.org/jira/browse/TS-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Xu updated TS-5053:
--
Description:
See title. Typically **argv is null terminated. And who are we to question 1000
years of tradition?
One example of an issue is that {{lib/ts/ink_args.cc}} actually relies on
**argv being null terminated. Interesting segfaults occur in plugins usings the
ATS argument parser.
was:
See title.
One example of an issue is that {{lib/ts/ink_args.cc}} actually relies on
**argv being null terminated. Interesting segfaults occur in plugins usings the
ATS argument parser.
> const char **argv passed to TSPluginInit is not null terminated
> ---
>
> Key: TS-5053
> URL: https://issues.apache.org/jira/browse/TS-5053
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> See title. Typically **argv is null terminated. And who are we to question
> 1000 years of tradition?
> One example of an issue is that {{lib/ts/ink_args.cc}} actually relies on
> **argv being null terminated. Interesting segfaults occur in plugins usings
> the ATS argument parser.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5053) const char **argv passed to TSPluginInit is not null terminated
[
https://issues.apache.org/jira/browse/TS-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Xu updated TS-5053:
--
Description:
See title. Typically **argv is null terminated in other systems. And who are we
to question 1000 years of tradition?
One example of an issue is that {{lib/ts/ink_args.cc}} actually relies on
**argv being null terminated. Interesting segfaults occur in plugins usings the
ATS argument parser.
was:
See title. Typically **argv is null terminated. And who are we to question 1000
years of tradition?
One example of an issue is that {{lib/ts/ink_args.cc}} actually relies on
**argv being null terminated. Interesting segfaults occur in plugins usings the
ATS argument parser.
> const char **argv passed to TSPluginInit is not null terminated
> ---
>
> Key: TS-5053
> URL: https://issues.apache.org/jira/browse/TS-5053
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> See title. Typically **argv is null terminated in other systems. And who are
> we to question 1000 years of tradition?
> One example of an issue is that {{lib/ts/ink_args.cc}} actually relies on
> **argv being null terminated. Interesting segfaults occur in plugins usings
> the ATS argument parser.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Updated] (TS-5053) const char **argv passed to TSPluginInit is not null terminated
[
https://issues.apache.org/jira/browse/TS-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Xu updated TS-5053:
--
Description:
See title.
One example of an issue is that {{lib/ts/ink_args.cc}} actually relies on
**argv being null terminated. Interesting segfaults occur in plugins usings the
ATS argument parser.
was:
See title.
An example of an issue this can cause is that {{lib/ts/ink_args.cc}} actually
relies on **argv being null terminated. Interesting segfaults occur in plugins
usings the ATS argument parser.
> const char **argv passed to TSPluginInit is not null terminated
> ---
>
> Key: TS-5053
> URL: https://issues.apache.org/jira/browse/TS-5053
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> See title.
> One example of an issue is that {{lib/ts/ink_args.cc}} actually relies on
> **argv being null terminated. Interesting segfaults occur in plugins usings
> the ATS argument parser.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Assigned] (TS-5053) const char **argv passed to TSPluginInit is not null terminated
[
https://issues.apache.org/jira/browse/TS-5053?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Daniel Xu reassigned TS-5053:
-
Assignee: Daniel Xu
> const char **argv passed to TSPluginInit is not null terminated
> ---
>
> Key: TS-5053
> URL: https://issues.apache.org/jira/browse/TS-5053
> Project: Traffic Server
> Issue Type: Bug
> Components: Plugins
>Reporter: Daniel Xu
>Assignee: Daniel Xu
>
> See title.
> An example of an issue this can cause is that {{lib/ts/ink_args.cc}} actually
> relies on **argv being null terminated. Interesting segfaults occur in
> plugins usings the ATS argument parser.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-5053) const char **argv passed to TSPluginInit is not null terminated
Daniel Xu created TS-5053:
-
Summary: const char **argv passed to TSPluginInit is not null
terminated
Key: TS-5053
URL: https://issues.apache.org/jira/browse/TS-5053
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Daniel Xu
See title.
An example of an issue this can cause is that {{lib/ts/ink_args.cc}} actually
relies on **argv being null terminated. Interesting segfaults occur in plugins
usings the ATS argument parser.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work logged] (TS-5050) The background_fetch plugin fails to check for config files relative to the config dir etc/trafficserver
[ https://issues.apache.org/jira/browse/TS-5050?focusedWorklogId=32041&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-32041 ] ASF GitHub Bot logged work on TS-5050: -- Author: ASF GitHub Bot Created on: 14/Nov/16 16:14 Start Date: 14/Nov/16 16:14 Worklog Time Spent: 10m Work Description: Github user jrushford commented on the issue: https://github.com/apache/trafficserver/pull/1218 @jpeach - tested and the fix consumes absolute paths, relative paths to install directory, and it now consumes config files relative to the config directory Issue Time Tracking --- Worklog Id: (was: 32041) Time Spent: 1h 20m (was: 1h 10m) > The background_fetch plugin fails to check for config files relative to the > config dir etc/trafficserver > > > Key: TS-5050 > URL: https://issues.apache.org/jira/browse/TS-5050 > Project: Traffic Server > Issue Type: Bug > Components: Plugins >Affects Versions: 6.2.0, 7.0.0, 7.1.0 >Reporter: John Rushford >Assignee: John Rushford > Fix For: 7.1.0 > > Time Spent: 1h 20m > Remaining Estimate: 0h > > We are currently using the background_fetch plugin with ATS 5.3.2 per remap. > We configure the background_fetch plugin in remap.config using the relative > path to a config file in etc/trafficserver. While testing ATS 6.2.1 with our > configs, I found that the background_fetch plugin no-longer looks for config > files relative to the etc/trafficserver configuration directory. > I think that this is a regression from 5.3.2 to 6.2.x and master. I found > that in configs.cc, TSConfigDirGet() is no-longer used to check for a config > file relative to etc/trafficserver. > I'm testing a patch to fix this. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #1218: TS-5050: The background_fetch plugin fails to che...
Github user jrushford commented on the issue: https://github.com/apache/trafficserver/pull/1218 @jpeach - tested and the fix consumes absolute paths, relative paths to install directory, and it now consumes config files relative to the config directory --- 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 #1216: Localized version of Boost.String_Ref.
Github user SolidWallOfCode commented on the issue: https://github.com/apache/trafficserver/pull/1216 Further work indicates that `string_ref` isn't going to be a suitable replacement for `ConstBuffer`. I will be taking a different approach. --- 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 #1216: Localized version of Boost.String_Ref.
Github user SolidWallOfCode closed the pull request at: https://github.com/apache/trafficserver/pull/1216 --- 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. ---
