You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@trafficserver.apache.org by "Alan M. Carroll (JIRA)" <ji...@apache.org> on 2013/08/01 18:27:49 UTC
[jira] [Resolved] (TS-1976) Invalid httpport argument passed from
traffic_manager to traffic_server
[ https://issues.apache.org/jira/browse/TS-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alan M. Carroll resolved TS-1976.
---------------------------------
Resolution: Fixed
Updated tweak to fix, verified in debugger.
> Invalid httpport argument passed from traffic_manager to traffic_server
> -----------------------------------------------------------------------
>
> Key: TS-1976
> URL: https://issues.apache.org/jira/browse/TS-1976
> Project: Traffic Server
> Issue Type: Bug
> Components: Configuration, Management, Security
> Reporter: Thach Tran
> Assignee: James Peach
> Fix For: 3.3.5
>
>
> I'm seeing a weird issue with invalid {{httpport}} option being passed from {{traffic_manager}} to {{traffic_server}} process. My ps output look a bit like this (I'm only running {{traffic_manager}} and not {{traffic_cop}})
> {noformat}
> ats 27565 0.0 0.2 374712 16176 pts/0 Sl 14:32 0:00 /trafficserver/bin/traffic_manager
> ats 27574 1.7 0.8 569440 52036 pts/0 Sl 14:32 0:03 /trafficserver/bin/traffic_server -M --httpport ip-in=[10.50.156.251]:443:fd=15:ssl,8443:fd=16:ssl?ݻ?
> {noformat}
> Notice some garbage characters at the end of {{traffic_server}}'s {{httpport}} arg. That also reflects in the log as follows.
> {noformat}
> WARNING: Invalid option 'ssl�ݻ' in port configuration '8443:fd=16:ssl�ݻ'
> {noformat}
> My server_ports in records.config is as follows.
> {noformat}
> CONFIG proxy.config.http.server_ports STRING ssl:443:ip-in=[10.50.156.251],ssl:8443
> {noformat}
> After spending some time looking at the code in {{LocalManager::startProxy}} ({{LocalManager.cc:1037}}), I believe the char {{Vec}} namely {{real_proxy_options}} is not being null-terminated despite the attempt of doing so in line 1037.
> {code}
> // NUL-terminate for the benefit of strtok and printf.
> real_proxy_options.append('\0');
> {code}
> This is, I think, because of the {{Vec}}'s implementation of appending from another {{Vec}} which explicitly check for if an element is 0 then don't append that element (line 352 in {{lib/ts/Vec.h}}).
> {code}
> template <class C, class A, int S> inline void
> Vec<C,A,S>::append(const Vec<C> &vv) {
> for (C *c = vv.v; c < vv.v + vv.n; c++)
> if (*c != 0)
> add(*c);
> }
> {code}
> I have no idea why the implementation of {{Vec}} is that way but I would think it's probably safer not messing around with a container class that has been used in many other places. So, my suggestion would be something like this in {{LocalManager}}.
> {code}
> // NUL-terminate for the benefit of strtok and printf.
> real_proxy_options.append("", 1);
> {code}
> Any thought would be very welcome.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira