[jira] [Created] (TS-1926) We don't build with Lua = 5.2
Leif Hedstrom created TS-1926: - Summary: We don't build with Lua = 5.2 Key: TS-1926 URL: https://issues.apache.org/jira/browse/TS-1926 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Leif Hedstrom Seems a few APIs got deprecated, and our builds fail with Lua 5.2 and later (tested to fail with 5.2.2 at least). One suggestion would be, for now, to not build the Lua plugin if the version is = 5.2. I have no idea how involved the real fixes would be. -- 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
[jira] [Updated] (TS-1926) We don't build with Lua = 5.2
[ https://issues.apache.org/jira/browse/TS-1926?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1926: -- Fix Version/s: 3.3.3 We don't build with Lua = 5.2 -- Key: TS-1926 URL: https://issues.apache.org/jira/browse/TS-1926 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Leif Hedstrom Fix For: 3.3.3 Seems a few APIs got deprecated, and our builds fail with Lua 5.2 and later (tested to fail with 5.2.2 at least). One suggestion would be, for now, to not build the Lua plugin if the version is = 5.2. I have no idea how involved the real fixes would be. -- 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
[jira] [Assigned] (TS-1891) Add double-free checking for reclaimable freelist
[ https://issues.apache.org/jira/browse/TS-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhao Yongming reassigned TS-1891: - Assignee: Zhao Yongming Add double-free checking for reclaimable freelist - Key: TS-1891 URL: https://issues.apache.org/jira/browse/TS-1891 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Yunkai Zhang Assignee: Zhao Yongming double-free checking is very useful for us to analyze memory issues. So, I introduce this feature to recalimable freelist. And，we found that this checking nearly don't affect the performance, so make the checking always. -- 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
[jira] [Updated] (TS-228) Solaris 64-bit SunPro long is 64-bit while for g++ 64-bit long is 32-bit, we shoud not use long anywhere in TS
[ https://issues.apache.org/jira/browse/TS-228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-228: - Fix Version/s: (was: 3.3.3) 3.5.0 Solaris 64-bit SunPro long is 64-bit while for g++ 64-bit long is 32-bit, we shoud not use long anywhere in TS Key: TS-228 URL: https://issues.apache.org/jira/browse/TS-228 Project: Traffic Server Issue Type: Bug Components: Cleanup Affects Versions: 2.1.0 Reporter: John Plevyak Assignee: James Peach Priority: Critical Fix For: 3.5.0 Solaris 64-bit SunPro long is 64-bit while for g++ 64-bit long is 32-bit. This is a potential can of worms which at the least is making records.snap incompatible but at worse could be the cause of other bugs. In any case we should not be using long in the TS code, but instead use either int which is always 32-bits or inkXXX of a particular size. -- 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
[jira] [Commented] (TS-1525) SPDY plugin will hang after several requests
[
https://issues.apache.org/jira/browse/TS-1525?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669350#comment-13669350
]
James Peach commented on TS-1525:
-
If you have questions about the SPDY plugin, let's discuss on the
us...@trafficserver.apache.org mailing list, or the #traffic-server IRC channel.
SPDY plugin will hang after several requests
Key: TS-1525
URL: https://issues.apache.org/jira/browse/TS-1525
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Conan Wang
Assignee: James Peach
Fix For: 3.3.5
In a spdy session, plugin will hang if reload the page several times in
browser.
Debug log:
{code}
(spdy.plugin) spdy_vconn_io:297 received 738 bytes
(spdy.plugin) spdy_vconn_io:297 received 754 bytes
(spdy.plugin) spdy_vconn_io:297 received 1442 bytes
(spdy.plugin) spdy_vconn_io:297 received 1458 bytes
repeat on each reload request
{code}
Some debug info, FYI:
When hanging, at spdy.cc:204 consume_spdy_frame(), nbytes from
TSIOBufferBlockReadStart will not grow. So (header.datalen = (nbytes -
spdy::message_header::size) can not pass test.
nbytes from TSIOBufferBlockReadStart is the available bytes of current block,
which I think should get from TSIOBufferReaderAvail(io-input.reader).
However, after replacing with TSIOBufferReaderAvail, other issues will raise:
parsing request header will fail or crash when decompressing header.
--
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
[jira] [Updated] (TS-871) Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
[
https://issues.apache.org/jira/browse/TS-871?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-871:
-
Fix Version/s: (was: 3.3.3)
3.5.0
Subversion (1.7) with serf fails with ATS in forward and reverse proxy mode
---
Key: TS-871
URL: https://issues.apache.org/jira/browse/TS-871
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.0.0
Reporter: Igor Galić
Assignee: Bryan Call
Fix For: 3.5.0
Attachments: ats_Thttp.debug.notime.txt, ats_Thttp.debug.txt,
revats_Thttp.debug.notime.txt, revats_Thttp.debug.txt, serf_proxy.cap,
serf_revproxy.cap, stats.diff, TS-871-20121107.diff, TS-871.diff
When accessing a remote subversion repository via http or https with svn 1.7,
it will currently timeout:
{noformat}
igalic@tynix ~/src/asf % svn co
http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http/
svn: E020014: Unable to connect to a repository at URL
'http://svn.apache.org/repos/asf/trafficserver/plugins/stats_over_http'
svn: E020014: Unspecified error message: 504 Connection Timed Out
1 igalic@tynix ~/src/asf %
{noformat}
I have started traffic_server -Thttp and captured the output, which I'm
attaching.
There's also a capture from the network.
--
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
[jira] [Commented] (TS-1280) cache control rule matching performance tweak
[ https://issues.apache.org/jira/browse/TS-1280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669353#comment-13669353 ] Leif Hedstrom commented on TS-1280: --- Is this going to land for v3.3.3 ? cache control rule matching performance tweak - Key: TS-1280 URL: https://issues.apache.org/jira/browse/TS-1280 Project: Traffic Server Issue Type: Improvement Components: Configuration, HTTP, Performance Affects Versions: 3.1.4 Reporter: Zhao Yongming Assignee: Bin Chen Fix For: 3.3.3 Attachments: url.patch in a big hosting env, you may create many rules in cache.config, the performance of the matching is critical, much liking remap, we need do some performance tweak: 1, how can we handle 1000+ rules? 2, can we handle the full URL match? 3, how to handle the path match, the better way ... place this issue as a track for all performance improvement -- 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
[jira] [Resolved] (TS-374) Potentially eliminate lock contention on HostDB
[ https://issues.apache.org/jira/browse/TS-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-374. -- Resolution: Fixed Potentially eliminate lock contention on HostDB --- Key: TS-374 URL: https://issues.apache.org/jira/browse/TS-374 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: Leif Hedstrom Assignee: Bryan Call Fix For: 3.3.3 When using as a reverse proxy, when a single (or very few) HostDB entries are under pressure, the try-lock there could cause us to reschedule. John suggests we look at this as a first step towards reducing latencies under high load, by avoiding holding the lock over multiple callbacks. -- 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
[jira] [Updated] (TS-1207) request for plugin cacheurl move into master tree
[ https://issues.apache.org/jira/browse/TS-1207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1207: -- Fix Version/s: (was: 3.3.3) 3.3.4 request for plugin cacheurl move into master tree - Key: TS-1207 URL: https://issues.apache.org/jira/browse/TS-1207 Project: Traffic Server Issue Type: New Feature Components: Plugins Affects Versions: 3.1.3 Reporter: Zhao Yongming Assignee: Phil Sorber Fix For: 3.3.4 from my testing, the cacheurl plugin is stable and usable in any version of 2.x 3.x, should we move into the meanline? -- 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
[jira] [Updated] (TS-1777) can not build on 32 bit system
[ https://issues.apache.org/jira/browse/TS-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1777: -- Fix Version/s: (was: 3.3.3) can not build on 32 bit system -- Key: TS-1777 URL: https://issues.apache.org/jira/browse/TS-1777 Project: Traffic Server Issue Type: Bug Components: Build Reporter: weijin Assignee: weijin Attachments: ts-1777.diff ats can not build on 32 bit system because of TS-1742 (volatile key word removed). -- 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
[jira] [Resolved] (TS-1777) can not build on 32 bit system
[ https://issues.apache.org/jira/browse/TS-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1777. --- Resolution: Cannot Reproduce I'm going to close this, without more details, I don't see what is wrong. We're building on quite a few 32-bit platforms without problem. can not build on 32 bit system -- Key: TS-1777 URL: https://issues.apache.org/jira/browse/TS-1777 Project: Traffic Server Issue Type: Bug Components: Build Reporter: weijin Assignee: weijin Attachments: ts-1777.diff ats can not build on 32 bit system because of TS-1742 (volatile key word removed). -- 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
[jira] [Updated] (TS-1895) 3.2.x - Building ATS on Ubuntu 10.04.4 LTS fails on make due to hwloc
[ https://issues.apache.org/jira/browse/TS-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1895: -- Fix Version/s: (was: 3.3.3) 3.2.x - Building ATS on Ubuntu 10.04.4 LTS fails on make due to hwloc - Key: TS-1895 URL: https://issues.apache.org/jira/browse/TS-1895 Project: Traffic Server Issue Type: Bug Components: Build Environment: Ubuntu 10.04 Reporter: Jason J. W. Williams Assignee: James Peach Building ATS 3.2.4 on Ubuntu 10.04.4 (AMD64) successfully completes ./configure, but on make errors out: ink_defs.cc: In function 'int ink_number_of_processors()': ink_defs.cc:121: error: 'HWLOC_OBJ_PU' was not declared in this scope This because HWLOC_OBJ_PU is not present in the hwloc version installed by Ubuntu 10.04.4: http://packages.ubuntu.com/lucid/libhwloc-dev Workaround is to configure with --disable-hwloc -- 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
[jira] [Commented] (TS-1895) 3.2.x - Building ATS on Ubuntu 10.04.4 LTS fails on make due to hwloc
[ https://issues.apache.org/jira/browse/TS-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669363#comment-13669363 ] Leif Hedstrom commented on TS-1895: --- What version is this bug for? Is this a backport proposal for v3.2.x? 3.2.x - Building ATS on Ubuntu 10.04.4 LTS fails on make due to hwloc - Key: TS-1895 URL: https://issues.apache.org/jira/browse/TS-1895 Project: Traffic Server Issue Type: Bug Components: Build Environment: Ubuntu 10.04 Reporter: Jason J. W. Williams Assignee: James Peach Building ATS 3.2.4 on Ubuntu 10.04.4 (AMD64) successfully completes ./configure, but on make errors out: ink_defs.cc: In function 'int ink_number_of_processors()': ink_defs.cc:121: error: 'HWLOC_OBJ_PU' was not declared in this scope This because HWLOC_OBJ_PU is not present in the hwloc version installed by Ubuntu 10.04.4: http://packages.ubuntu.com/lucid/libhwloc-dev Workaround is to configure with --disable-hwloc -- 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
[jira] [Updated] (TS-1897) Remap stopped working properly after remap refactoring
[ https://issues.apache.org/jira/browse/TS-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1897: -- Fix Version/s: (was: 3.3.3) Remap stopped working properly after remap refactoring -- Key: TS-1897 URL: https://issues.apache.org/jira/browse/TS-1897 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Assignee: James Peach Priority: Blocker -- 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
[jira] [Resolved] (TS-1897) Remap stopped working properly after remap refactoring
[ https://issues.apache.org/jira/browse/TS-1897?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1897. --- Resolution: Duplicate I believe this is fixed via another bug already. Remap stopped working properly after remap refactoring -- Key: TS-1897 URL: https://issues.apache.org/jira/browse/TS-1897 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: Leif Hedstrom Assignee: James Peach Priority: Blocker -- 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
[jira] [Updated] (TS-1923) 3.2.x - Fix resolve_logfield_string()
[ https://issues.apache.org/jira/browse/TS-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1923: -- Backport to Version: (was: 3.3.5) 3.2.x - Fix resolve_logfield_string() - Key: TS-1923 URL: https://issues.apache.org/jira/browse/TS-1923 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.2.4 Reporter: Yunkai Zhang Assignee: Igor Galić Fix For: 3.2.5 Attachments: 0001-Fix-resolve_logfield_string.patch When ATS receives a malicious request which URL is too long to hold by internal_msg_buffer, the internal_msg_buffer_size might be set to 0. As a result, the appended memory which allocated by ats_malloc() would be mistaken for the memory from ink_freelist, and would be free to ink_freelist finally. As this memory is larger than the one in ink_freelist, and all memory in the origin ink_freelist would not be reclaimed, so it wouldn't cause segment-fault, that is why we didn't notice it in the past. But after we use reclaimabe-freelist, this bug would cause segment-fault when use it to get inner meta-data or free it back to OS by unmmap(). === Now, we found the root cause which would lead to internal_msg_buffer_size to 0 while internal_msg_buffer is NOT NULL. That is resolve_logfiled_string() function. Let's fix it. -- 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
[jira] [Resolved] (TS-1889) refactor remap plugin request URL handling
[ https://issues.apache.org/jira/browse/TS-1889?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom resolved TS-1889. --- Resolution: Fixed refactor remap plugin request URL handling -- Key: TS-1889 URL: https://issues.apache.org/jira/browse/TS-1889 Project: Traffic Server Issue Type: Bug Components: Plugins, Remap API Reporter: James Peach Assignee: James Peach Fix For: 3.3.3 Traffic Server always rewrites URLs when it proxies them. The rewrite can be controlled by a configuration file or by code in a loadable plugin. The default URL rewriting code was duplicated for these two cases. This change removes the code duplication from the plugin rewrite case and simplifies the call site. It does not result in any change of behaviour. -- 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
[jira] [Updated] (TS-1923) 3.2.x - Fix resolve_logfield_string()
[ https://issues.apache.org/jira/browse/TS-1923?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1923: -- Fix Version/s: (was: 3.3.3) 3.2.5 3.2.x - Fix resolve_logfield_string() - Key: TS-1923 URL: https://issues.apache.org/jira/browse/TS-1923 Project: Traffic Server Issue Type: Bug Components: Core Affects Versions: 3.2.4 Reporter: Yunkai Zhang Assignee: Igor Galić Fix For: 3.2.5 Attachments: 0001-Fix-resolve_logfield_string.patch When ATS receives a malicious request which URL is too long to hold by internal_msg_buffer, the internal_msg_buffer_size might be set to 0. As a result, the appended memory which allocated by ats_malloc() would be mistaken for the memory from ink_freelist, and would be free to ink_freelist finally. As this memory is larger than the one in ink_freelist, and all memory in the origin ink_freelist would not be reclaimed, so it wouldn't cause segment-fault, that is why we didn't notice it in the past. But after we use reclaimabe-freelist, this bug would cause segment-fault when use it to get inner meta-data or free it back to OS by unmmap(). === Now, we found the root cause which would lead to internal_msg_buffer_size to 0 while internal_msg_buffer is NOT NULL. That is resolve_logfiled_string() function. Let's fix it. -- 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
[jira] [Updated] (TS-1378) IPV6 Addresses not recognized by proxy.local.incoming_ip_to_bind
[ https://issues.apache.org/jira/browse/TS-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1378: -- Fix Version/s: (was: 3.3.5) 3.5.0 IPV6 Addresses not recognized by proxy.local.incoming_ip_to_bind Key: TS-1378 URL: https://issues.apache.org/jira/browse/TS-1378 Project: Traffic Server Issue Type: Bug Components: HTTP, Network Affects Versions: 3.2.0 Environment: ubuntu 10.04 Reporter: Kingsley Foreman Assignee: Alan M. Carroll Fix For: 3.5.0 IPv6 addresses always report as an error on proxy.local.incoming_ip_to_bind an example LOCAL proxy.local.incoming_ip_to_bind STRING 127.0.0.1 ::1 WARNING: 'proxy.local.incoming_ip_to_bind' has an value '::1' that is not recognized as an IP address, ignored. -- 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
[jira] [Updated] (TS-1510) Large files being purged from cache incorrectly
[ https://issues.apache.org/jira/browse/TS-1510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1510: -- Fix Version/s: (was: 3.3.5) 3.3.3 Large files being purged from cache incorrectly --- Key: TS-1510 URL: https://issues.apache.org/jira/browse/TS-1510 Project: Traffic Server Issue Type: Bug Components: Cache Affects Versions: 3.3.0 Environment: Ubuntu 10.04 and 12.04 Reporter: Kingsley Foreman Labels: A Fix For: 3.3.3 With an empty cache of 120gb. I've added two files. 1. 2mb file 2. 3gb file. after 30min 2mb file remains in cache rechecks home (304) serves from cache 3gb file not i cache, and does a 200 request from the origin server like it has been cleared from cache. There is plenty of space so it isn't expiring, so really it should do a 304 not a 200 to the origin server. -- 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
[jira] [Commented] (TS-1378) IPV6 Addresses not recognized by proxy.local.incoming_ip_to_bind
[ https://issues.apache.org/jira/browse/TS-1378?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669370#comment-13669370 ] Leif Hedstrom commented on TS-1378: --- I'm moving this out to v3.5.0, Alan, please move it back if this needs to go into v3.4.0 IPV6 Addresses not recognized by proxy.local.incoming_ip_to_bind Key: TS-1378 URL: https://issues.apache.org/jira/browse/TS-1378 Project: Traffic Server Issue Type: Bug Components: HTTP, Network Affects Versions: 3.2.0 Environment: ubuntu 10.04 Reporter: Kingsley Foreman Assignee: Alan M. Carroll Fix For: 3.5.0 IPv6 addresses always report as an error on proxy.local.incoming_ip_to_bind an example LOCAL proxy.local.incoming_ip_to_bind STRING 127.0.0.1 ::1 WARNING: 'proxy.local.incoming_ip_to_bind' has an value '::1' that is not recognized as an IP address, ignored. -- 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
[jira] [Updated] (TS-667) Ability to keep traffic server from initializing the wrong disks when using RAW disk mode.
[ https://issues.apache.org/jira/browse/TS-667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-667: - Fix Version/s: (was: 3.3.5) sometime Ability to keep traffic server from initializing the wrong disks when using RAW disk mode. -- Key: TS-667 URL: https://issues.apache.org/jira/browse/TS-667 Project: Traffic Server Issue Type: Improvement Components: Cache, Configuration Reporter: David Robinson Priority: Minor Labels: A, features Fix For: sometime When disk devices are configured in storage.config for RAW mode they are automatically initialized when traffic server first starts up. If disk device names change later due to adding/removing disks or kernel changes trafficserver will overwrite disks that the user may not want to be cache disks. This leads to data loss on the affected disks. Maybe a feature could be added similar to squid's -z where cache disks must be explicitly initialized before they can be used. Or a configuration variable that changes trafficserver's initialization behavior. (6:49:06 PM) zwoop: so, maybe have a few settings for the config (6:49:06 PM) zwoop: 0 - Let it reinitialize cache as it likes (6:49:06 PM) zwoop: 1 - Only initialize cache explicitly (6:49:06 PM) zwoop: 2 - Only initialize cache explicitly, and refuse to start up if we detect a cache disk with bad header -- 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
[jira] [Updated] (TS-203) config files ownership
[ https://issues.apache.org/jira/browse/TS-203?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-203: - Fix Version/s: (was: 3.3.5) sometime config files ownership -- Key: TS-203 URL: https://issues.apache.org/jira/browse/TS-203 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Leif Hedstrom Priority: Minor Fix For: sometime It's semi-odd that the admin user (nobody) is also the user as to which traffic_server process changes it's euid to. This means that the traffic_server process has write permissions on the config files. -- 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
[jira] [Updated] (TS-1606) Log buffers are not flushed periodically when TS is launched with NO_REMOTE_MANAGEMENT flag
[
https://issues.apache.org/jira/browse/TS-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1606:
--
Fix Version/s: (was: 3.3.3)
3.5.0
Log buffers are not flushed periodically when TS is launched with
NO_REMOTE_MANAGEMENT flag
---
Key: TS-1606
URL: https://issues.apache.org/jira/browse/TS-1606
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.3.0, 3.2.0
Reporter: Yakov Markovitch
Assignee: Leif Hedstrom
Fix For: 3.5.0
Attachments: trafficserver-periodic-tasks.patch
When TS binary is launched with NO_REMOTE_MANAGEMENT flag (e.g., when
launched not as a daemon but directly - this is extremely convenient for
debugging), the PeriodicWakeup event is not scheduled.
As a result, Log::flush_thread_main() does not wake up periodically, but only
on log buffer overflow. Coupled with a horribly wrong activation check in
Log::flush_thread_main():
{code}
if (now last_time) {
if ((now % PERIODIC_TASKS_INTERVAL) == 0) {
// We run only when waken up at the moment which is exact
// multiple of PERIODIC_TASKS_INTERVAL!
{code}
this leads to that probability of any log output is low.
--
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
[jira] [Assigned] (TS-1606) Log buffers are not flushed periodically when TS is launched with NO_REMOTE_MANAGEMENT flag
[
https://issues.apache.org/jira/browse/TS-1606?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-1606:
-
Assignee: (was: Leif Hedstrom)
Log buffers are not flushed periodically when TS is launched with
NO_REMOTE_MANAGEMENT flag
---
Key: TS-1606
URL: https://issues.apache.org/jira/browse/TS-1606
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.3.0, 3.2.0
Reporter: Yakov Markovitch
Fix For: 3.5.0
Attachments: trafficserver-periodic-tasks.patch
When TS binary is launched with NO_REMOTE_MANAGEMENT flag (e.g., when
launched not as a daemon but directly - this is extremely convenient for
debugging), the PeriodicWakeup event is not scheduled.
As a result, Log::flush_thread_main() does not wake up periodically, but only
on log buffer overflow. Coupled with a horribly wrong activation check in
Log::flush_thread_main():
{code}
if (now last_time) {
if ((now % PERIODIC_TASKS_INTERVAL) == 0) {
// We run only when waken up at the moment which is exact
// multiple of PERIODIC_TASKS_INTERVAL!
{code}
this leads to that probability of any log output is low.
--
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
[jira] [Updated] (TS-1919) Eliminate CacheLookupHttpConfig
[ https://issues.apache.org/jira/browse/TS-1919?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1919: -- Fix Version/s: 3.3.3 Eliminate CacheLookupHttpConfig --- Key: TS-1919 URL: https://issues.apache.org/jira/browse/TS-1919 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.3 We have a notion of creating (and transmitting) a very tiny subset of HttpConfigParams, in a struct named CacheLookupHttpConfig. As it turns out, this is generally not used, and as far as I can tell, cluster config provides the same / similar functionality (assuring that all nodes in the cluster uses the same config). One complication with this CacheLookupHttpConfig struct is that it sort of violates modularity, in that the I/O core, clustering and HTTPSM share this partial HTTP config in a non-opaque way. I have a patch that eliminates this (I'll post it later), but there are two thoughts / questions I'd like to discuss. 1) Do we feel it adequate to use the cluster config mechanism of distributing / sharing configurations across the cluster? Or do we really think that it's necessary to transfer the configs as part of every Cluster response message? 2) If we agree to eliminate the CacheLookupHttpConfig in favor of just using HttpConfigParam's (which are synchronized between cluster nodes), how important is it to preserve compatibility in the Cluster protocol? Right now, my patch does not do this (I'd break clustering between e.g. ATS v3.2 and ATS v3.4). For 2), we have a few options, the cleanest probably involves knowing the version of the Cluster message (does that exist today?). Before I go down that route, I'd like to ask the people using clustering if they feel it important to retain compatibility such that you can run a cluster with a mix of v3.2 and v3.4 nodes. -- 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
[jira] [Commented] (TS-1895) 3.2.x - Building ATS on Ubuntu 10.04.4 LTS fails on make due to hwloc
[ https://issues.apache.org/jira/browse/TS-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669405#comment-13669405 ] Jason J. W. Williams commented on TS-1895: -- That was my hope. 3.2.x - Building ATS on Ubuntu 10.04.4 LTS fails on make due to hwloc - Key: TS-1895 URL: https://issues.apache.org/jira/browse/TS-1895 Project: Traffic Server Issue Type: Bug Components: Build Environment: Ubuntu 10.04 Reporter: Jason J. W. Williams Assignee: James Peach Building ATS 3.2.4 on Ubuntu 10.04.4 (AMD64) successfully completes ./configure, but on make errors out: ink_defs.cc: In function 'int ink_number_of_processors()': ink_defs.cc:121: error: 'HWLOC_OBJ_PU' was not declared in this scope This because HWLOC_OBJ_PU is not present in the hwloc version installed by Ubuntu 10.04.4: http://packages.ubuntu.com/lucid/libhwloc-dev Workaround is to configure with --disable-hwloc -- 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
[jira] [Updated] (TS-1827) minor improvement of combo_handler plugin
[
https://issues.apache.org/jira/browse/TS-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1827:
--
Attachment: TS-1827.diff
minor improvement of combo_handler plugin
-
Key: TS-1827
URL: https://issues.apache.org/jira/browse/TS-1827
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Conan Wang
Assignee: Leif Hedstrom
Fix For: 3.3.3
Attachments: TS-1827.diff
Based on TS-1053, I've made some minor improvements. Community can select the
general ones to review.
Changes: (separately pasted on pastebin temporally; may provide with commits
later after TS-1053 is solved on git master):
# use HOST header as default bucket http://pastebin.com/pGHfLaHR
Original code use the first segment of Host as the default bucket and it's
not that expandable (two different combo domain may have same leading
segment). Moreover, the initial default bucket(l) will not be used, because
all requests should have a HOST.
# sub-file's path need to contain querystring, i.e. question mark(?) is
part of the file path, not the delimiter http://pastebin.com/HvMJBQw0
We use querystring to version each single sub-file in the combined url. If we
want to update/purge one of them, it can be simply accomplished by changing
the version of sub-file. (If not, you have to purge both the combined url and
sub-file url which is relatively hard to know the latter one when you are not
very familiar with ATS. Of course you can alter the filename if possible in
your site.)
Then the combo url could be like
http://example.com/combo?file1?v=2012file2?v=2013
# request hangs when combo url has no querystring http://pastebin.com/d34ZJDzQ
# make plugin per-remap enabled/disabled http://pastebin.com/YTaDYvh2
It's implemented by adding some remap code and make global part intercepted
in TS_EVENT_HTTP_OS_DNS instead of TS_EVENT_HTTP_READ_REQUEST_HDR in order to
read the flag set in TSRemapDoRemap.
So remap.config will be: {code}
maphttp://example.com http://os.example.com @plugin=combo_handler.so
maphttp://localhost/example.com http://os.example.com
maphttp://other.com http://os.other.com # combo for this channel is
disabled
{code}
# limit sub-file max count and querystring length for potential problems
http://pastebin.com/cmBCuCNB
# log failed url http://pastebin.com/bNezeaz0
They were tested on 3.0.x.
--
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
[jira] [Commented] (TS-1827) minor improvement of combo_handler plugin
[
https://issues.apache.org/jira/browse/TS-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669452#comment-13669452
]
Leif Hedstrom commented on TS-1827:
---
Two comments on the patch:
1) There's no need to allocate the int for plugin_enabled, just set the void*
(with appropriate casting) to 1.
2) With this patch, there is no longer possible to enable the combo_handler as
a global, right? Is that as intended? Meaning, the only way this will work is
by also invoking the plugin in a remap rule, right?
I'm attaching an updated patch for issue #1 above, please review that.
minor improvement of combo_handler plugin
-
Key: TS-1827
URL: https://issues.apache.org/jira/browse/TS-1827
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Conan Wang
Assignee: Leif Hedstrom
Fix For: 3.3.3
Attachments: TS-1827.diff
Based on TS-1053, I've made some minor improvements. Community can select the
general ones to review.
Changes: (separately pasted on pastebin temporally; may provide with commits
later after TS-1053 is solved on git master):
# use HOST header as default bucket http://pastebin.com/pGHfLaHR
Original code use the first segment of Host as the default bucket and it's
not that expandable (two different combo domain may have same leading
segment). Moreover, the initial default bucket(l) will not be used, because
all requests should have a HOST.
# sub-file's path need to contain querystring, i.e. question mark(?) is
part of the file path, not the delimiter http://pastebin.com/HvMJBQw0
We use querystring to version each single sub-file in the combined url. If we
want to update/purge one of them, it can be simply accomplished by changing
the version of sub-file. (If not, you have to purge both the combined url and
sub-file url which is relatively hard to know the latter one when you are not
very familiar with ATS. Of course you can alter the filename if possible in
your site.)
Then the combo url could be like
http://example.com/combo?file1?v=2012file2?v=2013
# request hangs when combo url has no querystring http://pastebin.com/d34ZJDzQ
# make plugin per-remap enabled/disabled http://pastebin.com/YTaDYvh2
It's implemented by adding some remap code and make global part intercepted
in TS_EVENT_HTTP_OS_DNS instead of TS_EVENT_HTTP_READ_REQUEST_HDR in order to
read the flag set in TSRemapDoRemap.
So remap.config will be: {code}
maphttp://example.com http://os.example.com @plugin=combo_handler.so
maphttp://localhost/example.com http://os.example.com
maphttp://other.com http://os.other.com # combo for this channel is
disabled
{code}
# limit sub-file max count and querystring length for potential problems
http://pastebin.com/cmBCuCNB
# log failed url http://pastebin.com/bNezeaz0
They were tested on 3.0.x.
--
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
[jira] [Updated] (TS-1891) Add double-free checking for reclaimable freelist
[ https://issues.apache.org/jira/browse/TS-1891?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yunkai Zhang updated TS-1891: - Attachment: 0001-Add-double-free-checking-for-reclaimable-freelist-V6.patch Add double-free checking for reclaimable freelist - Key: TS-1891 URL: https://issues.apache.org/jira/browse/TS-1891 Project: Traffic Server Issue Type: New Feature Components: Core Reporter: Yunkai Zhang Assignee: Zhao Yongming Attachments: 0001-Add-double-free-checking-for-reclaimable-freelist-V6.patch double-free checking is very useful for us to analyze memory issues. So, I introduce this feature to recalimable freelist. And，we found that this checking nearly don't affect the performance, so make the checking always. -- 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
[jira] [Created] (TS-1927) Make ats_base64_* able to handle the URL variant
Phil Sorber created TS-1927: --- Summary: Make ats_base64_* able to handle the URL variant Key: TS-1927 URL: https://issues.apache.org/jira/browse/TS-1927 Project: Traffic Server Issue Type: Improvement Reporter: Phil Sorber https://en.wikipedia.org/wiki/Base64#URL_applications We can make the decode function handle these properly without much work. The encode might be a little more involved and require some new API functions. -- 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
[jira] [Resolved] (TS-1851) turn HostDBInfo back into a POD type
[ https://issues.apache.org/jira/browse/TS-1851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-1851. - Resolution: Fixed turn HostDBInfo back into a POD type Key: TS-1851 URL: https://issues.apache.org/jira/browse/TS-1851 Project: Traffic Server Issue Type: Bug Components: DNS Reporter: James Peach Assignee: James Peach Fix For: 3.3.3 Somewhere down the line HostDBInfo grew enough constructor complexity that it became a non-POD type. The allocation treats it like a POD type, so we should make sure that the compiler treats is the same way. -- 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
[jira] [Assigned] (TS-1895) 3.2.x - Building ATS on Ubuntu 10.04.4 LTS fails on make due to hwloc
[ https://issues.apache.org/jira/browse/TS-1895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach reassigned TS-1895: --- Assignee: (was: James Peach) 3.2.x - Building ATS on Ubuntu 10.04.4 LTS fails on make due to hwloc - Key: TS-1895 URL: https://issues.apache.org/jira/browse/TS-1895 Project: Traffic Server Issue Type: Bug Components: Build Environment: Ubuntu 10.04 Reporter: Jason J. W. Williams Building ATS 3.2.4 on Ubuntu 10.04.4 (AMD64) successfully completes ./configure, but on make errors out: ink_defs.cc: In function 'int ink_number_of_processors()': ink_defs.cc:121: error: 'HWLOC_OBJ_PU' was not declared in this scope This because HWLOC_OBJ_PU is not present in the hwloc version installed by Ubuntu 10.04.4: http://packages.ubuntu.com/lucid/libhwloc-dev Workaround is to configure with --disable-hwloc -- 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
[jira] [Commented] (TS-1825) TSPortDescriptorAccept() does not use its TSCont contp parameter
[
https://issues.apache.org/jira/browse/TS-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669573#comment-13669573
]
ASF subversion and git services commented on TS-1825:
-
Commit 8ed70b69b00d277c35fc20c6de46ebef974a2d51 in branch refs/heads/master
from [~jpe...@apache.org]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8ed70b6 ]
TS-1825: TSPortDescriptorAccept does not use it's argument
TSPortDescriptorAccept never calls the acceptance continuation that
it takes as an argument. Fix TSPortDescriptorAccept so that it
actually uses the continuation from the caller. Fix the corresponding
unit test.
Refactor the SDK_API_TSNetVConn and SDK_API_TSPortDescriptor tests
and update the them so that them actually verify the connection on
the server side. Generalize them to not use any global variables.
over
TSPortDescriptorAccept() does not use its TSCont contp parameter
Key: TS-1825
URL: https://issues.apache.org/jira/browse/TS-1825
Project: Traffic Server
Issue Type: Bug
Components: TS API
Reporter: Leif Hedstrom
Assignee: James Peach
Priority: Blocker
Fix For: 3.3.3
This looks odd:
{code}
TSReturnCode
TSPortDescriptorAccept(TSPortDescriptor descp, TSCont contp)
{
HttpProxyPort * port = (HttpProxyPort *)descp;
return start_HttpProxyPort(*port, 0 /* nthreads */) ? TS_SUCCESS : TS_ERROR;
}
{code}
Assuming that (as per the IRC discussions) TSPortDescriptAccept() should work
something similar to TSNetAccept, shouldn't it be using the contp for
callbacks?
--
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
[jira] [Resolved] (TS-1812) remove syslog_thr_init
[ https://issues.apache.org/jira/browse/TS-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach resolved TS-1812. - Resolution: Fixed This happened in 10b83ec2744a1b662837202af787191db375206f remove syslog_thr_init -- Key: TS-1812 URL: https://issues.apache.org/jira/browse/TS-1812 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: James Peach Assignee: James Peach Fix For: 3.3.3 The comments in proxy/Main.cc indicate that syslog_thr_init() used to be there to support DEC Alpha. Since Alpha is dead and syslog_thr_init() doesn't actuly o anything any more, let's remove it so that we don't have to put it in silly stubs everywhere. -- 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
[jira] [Commented] (TS-1812) remove syslog_thr_init
[ https://issues.apache.org/jira/browse/TS-1812?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669579#comment-13669579 ] ASF subversion and git services commented on TS-1812: - Commit 2712c303655e41ef9ae7a2b341755b570b3225c1 in branch refs/heads/master from [~jpe...@apache.org] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2712c30 ] Add TS-1812 to CHANGES. remove syslog_thr_init -- Key: TS-1812 URL: https://issues.apache.org/jira/browse/TS-1812 Project: Traffic Server Issue Type: Improvement Components: Core Reporter: James Peach Assignee: James Peach Fix For: 3.3.3 The comments in proxy/Main.cc indicate that syslog_thr_init() used to be there to support DEC Alpha. Since Alpha is dead and syslog_thr_init() doesn't actuly o anything any more, let's remove it so that we don't have to put it in silly stubs everywhere. -- 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
[jira] [Commented] (TS-1827) minor improvement of combo_handler plugin
[
https://issues.apache.org/jira/browse/TS-1827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669607#comment-13669607
]
Conan Wang commented on TS-1827:
I'll test the issue 1 later.
For issue 2, right, it's as intended, at least for CDN (usually only a few
customers among all will enable combo feature). And it looks safer for ATS
users to adopt this plugin.
Should we support the old manner(if not existing combo remap rule, make it
enabled globally for all channels which is a little confusing)?
minor improvement of combo_handler plugin
-
Key: TS-1827
URL: https://issues.apache.org/jira/browse/TS-1827
Project: Traffic Server
Issue Type: Improvement
Components: Plugins
Reporter: Conan Wang
Assignee: Leif Hedstrom
Fix For: 3.3.3
Attachments: TS-1827.diff
Based on TS-1053, I've made some minor improvements. Community can select the
general ones to review.
Changes: (separately pasted on pastebin temporally; may provide with commits
later after TS-1053 is solved on git master):
# use HOST header as default bucket http://pastebin.com/pGHfLaHR
Original code use the first segment of Host as the default bucket and it's
not that expandable (two different combo domain may have same leading
segment). Moreover, the initial default bucket(l) will not be used, because
all requests should have a HOST.
# sub-file's path need to contain querystring, i.e. question mark(?) is
part of the file path, not the delimiter http://pastebin.com/HvMJBQw0
We use querystring to version each single sub-file in the combined url. If we
want to update/purge one of them, it can be simply accomplished by changing
the version of sub-file. (If not, you have to purge both the combined url and
sub-file url which is relatively hard to know the latter one when you are not
very familiar with ATS. Of course you can alter the filename if possible in
your site.)
Then the combo url could be like
http://example.com/combo?file1?v=2012file2?v=2013
# request hangs when combo url has no querystring http://pastebin.com/d34ZJDzQ
# make plugin per-remap enabled/disabled http://pastebin.com/YTaDYvh2
It's implemented by adding some remap code and make global part intercepted
in TS_EVENT_HTTP_OS_DNS instead of TS_EVENT_HTTP_READ_REQUEST_HDR in order to
read the flag set in TSRemapDoRemap.
So remap.config will be: {code}
maphttp://example.com http://os.example.com @plugin=combo_handler.so
maphttp://localhost/example.com http://os.example.com
maphttp://other.com http://os.other.com # combo for this channel is
disabled
{code}
# limit sub-file max count and querystring length for potential problems
http://pastebin.com/cmBCuCNB
# log failed url http://pastebin.com/bNezeaz0
They were tested on 3.0.x.
--
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
[jira] [Updated] (TS-1882) ATS doesn't warn about unknown config items
[ https://issues.apache.org/jira/browse/TS-1882?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1882: -- Fix Version/s: (was: 3.3.3) 3.3.4 ATS doesn't warn about unknown config items --- Key: TS-1882 URL: https://issues.apache.org/jira/browse/TS-1882 Project: Traffic Server Issue Type: Bug Components: Configuration Reporter: Ebrahim Mohammadi Assignee: Leif Hedstrom Fix For: 3.3.4 Apache Traffic Server doesn't warn about unknown configuration file items. It can cause huge confusions, specially in case of trying to get features of a newer version to work on an older installed version by mistake, as I found out the hard way! -- 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
[jira] [Updated] (TS-1460) 3.0.x - make install should work as non-root user
[ https://issues.apache.org/jira/browse/TS-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1460: -- Fix Version/s: (was: 3.2.5) 3.0.x - make install should work as non-root user - Key: TS-1460 URL: https://issues.apache.org/jira/browse/TS-1460 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: Jan-Frode Myklebust Priority: Trivial Attachments: 0001-Enabling-installing-as-non-root.patch, TS-1295.diff make install should work as non-root user. Requirng root is bad practice and causes problems for the fedora build system. -- 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
[jira] [Updated] (TS-1460) 3.0.x - make install should work as non-root user
[ https://issues.apache.org/jira/browse/TS-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1460: -- Fix Version/s: 3.0.6 3.0.x - make install should work as non-root user - Key: TS-1460 URL: https://issues.apache.org/jira/browse/TS-1460 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: Jan-Frode Myklebust Priority: Trivial Fix For: 3.0.6 Attachments: 0001-Enabling-installing-as-non-root.patch, TS-1295.diff make install should work as non-root user. Requirng root is bad practice and causes problems for the fedora build system. -- 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
[jira] [Assigned] (TS-1460) 3.0.x - make install should work as non-root user
[ https://issues.apache.org/jira/browse/TS-1460?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1460: - Assignee: (was: Leif Hedstrom) 3.0.x - make install should work as non-root user - Key: TS-1460 URL: https://issues.apache.org/jira/browse/TS-1460 Project: Traffic Server Issue Type: Improvement Components: Build Reporter: Jan-Frode Myklebust Priority: Trivial Fix For: 3.2.5 Attachments: 0001-Enabling-installing-as-non-root.patch, TS-1295.diff make install should work as non-root user. Requirng root is bad practice and causes problems for the fedora build system. -- 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
[jira] [Updated] (TS-1901) Update all build instructions in prep for v3.4.0
[ https://issues.apache.org/jira/browse/TS-1901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1901: -- Fix Version/s: (was: 3.3.3) 3.3.4 Update all build instructions in prep for v3.4.0 Key: TS-1901 URL: https://issues.apache.org/jira/browse/TS-1901 Project: Traffic Server Issue Type: Bug Components: Build Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.4 We should update the README and INSTALL, as well as the CWIKI pages for all build instructions. -- 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
[jira] [Updated] (TS-1776) Range requests not working right in 3.2.4
[ https://issues.apache.org/jira/browse/TS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1776: -- Fix Version/s: (was: 3.3.3) 3.2.5 Range requests not working right in 3.2.4 - Key: TS-1776 URL: https://issues.apache.org/jira/browse/TS-1776 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.4 Reporter: William Bardwell Assignee: William Bardwell Fix For: 3.2.5 With the patch in 3.2.4 for TS-1575 that tries to turn off the new range code, range requests aren't work right for me. The responses have all of the multi-part header markings, but the Content-Length and Content-Range headers should be used for single range requests. Also when I do a range that starts 0, the content is wrong. -- 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
[jira] [Commented] (TS-1776) Range requests not working right in 3.2.4
[ https://issues.apache.org/jira/browse/TS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669709#comment-13669709 ] Leif Hedstrom commented on TS-1776: --- There has been other reports on v3.2.4 not working with Range requests (including segfaults). We should aim to fix this before a v3.2.5 relase IMO. Alan M. Carroll: Is this something you have, or will/can, look at as well? Range requests not working right in 3.2.4 - Key: TS-1776 URL: https://issues.apache.org/jira/browse/TS-1776 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.4 Reporter: William Bardwell Assignee: William Bardwell Priority: Blocker Fix For: 3.2.5 With the patch in 3.2.4 for TS-1575 that tries to turn off the new range code, range requests aren't work right for me. The responses have all of the multi-part header markings, but the Content-Length and Content-Range headers should be used for single range requests. Also when I do a range that starts 0, the content is wrong. -- 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
[jira] [Updated] (TS-1776) Range requests not working right in 3.2.4
[ https://issues.apache.org/jira/browse/TS-1776?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1776: -- Priority: Blocker (was: Major) Range requests not working right in 3.2.4 - Key: TS-1776 URL: https://issues.apache.org/jira/browse/TS-1776 Project: Traffic Server Issue Type: Bug Components: HTTP Affects Versions: 3.2.4 Reporter: William Bardwell Assignee: William Bardwell Priority: Blocker Fix For: 3.2.5 With the patch in 3.2.4 for TS-1575 that tries to turn off the new range code, range requests aren't work right for me. The responses have all of the multi-part header markings, but the Content-Length and Content-Range headers should be used for single range requests. Also when I do a range that starts 0, the content is wrong. -- 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
[jira] [Updated] (TS-1330) Logging related segfault in 3.2.0
[
https://issues.apache.org/jira/browse/TS-1330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1330:
--
Fix Version/s: (was: 3.3.5)
3.3.4
Logging related segfault in 3.2.0
-
Key: TS-1330
URL: https://issues.apache.org/jira/browse/TS-1330
Project: Traffic Server
Issue Type: Bug
Components: Logging
Affects Versions: 3.2.0
Environment: ATS 3.2.0 on RHEL 6.2 64-bit
Reporter: David Carlin
Assignee: Leif Hedstrom
Priority: Critical
Labels: A, crash
Fix For: 3.3.4
I observed the following crash once on one of our ATS boxes - possibly
related to TS-1240
Jul 2 13:56:56 l2 traffic_server[25853]: {0x2b0a391e1700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
error: Connection reset by peer
Jul 2 13:59:56 l2 kernel: [ET_NET 1][25855]: segfault at c ip
0058e083 sp 2b0a2982b740 error 6
Jul 2 13:59:56 l2 kernel: [ET_NET 3][25857]: segfault at 84 ip
0058e083 sp 2b0a29a31740 error 6 in traffic_server[40+34]
Jul 2 13:59:56 l2 kernel: in traffic_server[40+34]
Jul 2 14:02:59 l2 traffic_cop[25901]: (test) read timeout [18 ]
Jul 2 14:02:59 l2 traffic_cop[25901]: server heartbeat failed [1]
Jul 2 14:03:08 l2 traffic_manager[25826]: {0x7f3f088607e0} FATAL:
[LocalManager::pollMgmtProcessServer] Error in read (errno: 104)
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} FATAL: (last
system error 104: Connection reset by peer)
Jul 2 14:03:09 l2 traffic_cop[25901]: cannot find traffic_server [1]
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} ERROR:
[LocalManager::sendMgmtMsgToProcesses] Error writing message
Jul 2 14:03:09 l2 traffic_manager[25826]: {0x7f3f088607e0} ERROR: (last
system error 32: Broken pipe)
Jul 2 14:03:12 l2 traffic_cop[25901]: cop received child status signal
[25826 35584]
Jul 2 14:03:12 l2 traffic_cop[25901]: traffic_manager not running, making
sure traffic_server is dead
Jul 2 14:03:12 l2 traffic_cop[25901]: spawning traffic_manager
Jul 2 14:03:13 l2 traffic_manager[18267]: NOTE: --- Manager Starting ---
Jul 2 14:03:13 l2 traffic_manager[18267]: NOTE: Manager Version: Apache
Traffic Server - traffic_manager - 3.2.0 - (build # 52518 on Jun 25 2012 at
18:22:12)
Jul 2 14:03:13 l2 traffic_manager[18267]: {0x7fe63de3f7e0} STATUS: opened
/home/y/logs/trafficserver/manager.log
Jul 2 14:03:15 l2 traffic_server[18322]: NOTE: --- Server Starting ---
Jul 2 14:03:15 l2 traffic_server[18322]: NOTE: Server Version: Apache
Traffic Server - traffic_server - 3.2.0 - (build # 52518 on Jun 25 2012 at
18:22:31)
Jul 2 14:03:15 l2 traffic_server[18322]: {0x2b77573ab860} STATUS: opened
/home/y/logs/trafficserver/diags.log
Jul 2 14:03:15 l2 traffic_server[18322]: {0x2b77573ab860} ERROR: Cannot
insert duplicate!
Jul 2 14:03:22 l2 traffic_cop[25901]: server heartbeat succeeded
[Jul 2 13:56:56.304] Server {0x2b0a391e1700} ERROR:
[SSL_NetVConnection::ssl_read_from_net] SSL_ERROR_SYSCALL, underlying IO
error: Connection reset by peer
NOTE: Traffic Server received Sig 11: Segmentation fault
NOTE: Traffic Server received Sig 11: Segmentation fault
/home/y/bin/traffic_server - STACK TRACE:
/home/y/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x3b54e0f4a0]
/lib64/libpthread.so.0[0x3b54e0f4a0]
/home/y/bin/traffic_server(_ZN9LogBuffer14checkout_writeEPmm+0x153)[0x58e083]
/home/y/bin/traffic_server(_ZN9LogObject15_checkout_writeEPmm+0xa8)[0x5a64c8]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x2f0)[0x5a7e30]
/home/y/bin/traffic_server(_ZN9LogBuffer14checkout_writeEPmm+0x153)[0x58e083]
/home/y/bin/traffic_server(_ZN9LogObject15_checkout_writeEPmm+0xa8)[0x5a64c8]
/home/y/bin/traffic_server(_ZN9LogObject3logEP9LogAccessPc+0x2f0)[0x5a7e30]
/home/y/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x146)[0x58f506]
/home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x630)[0x526c50]
/home/y/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x146)[0x58f506]
/home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x928)[0x52b548]
/home/y/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x630)[0x526c50]
/home/y/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x928)[0x52b548]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x198)[0x52b868]
/home/y/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0xde)[0x56c3ee]
/home/y/bin/traffic_server[0x6736a1]
/home/y/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x198)[0x52b868]
/home/y/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x847)[0x675517]
/home/y/bin/traffic_server[0x672f81]
[jira] [Updated] (TS-1928) False error / warning when setting log rotation size to exactly 10
[
https://issues.apache.org/jira/browse/TS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1928:
--
Component/s: Logging
Fix Version/s: 3.3.3
Assignee: Leif Hedstrom
False error / warning when setting log rotation size to exactly 10
--
Key: TS-1928
URL: https://issues.apache.org/jira/browse/TS-1928
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 3.3.3
{code}
[May 29 14:52:50.402] Server {0x7f7e20191840} NOTE: Rolling size invalid(10)
for /opt/ats/var/log/trafficserver/squid.blog, setting it to 10 MB
{code}
As it turns out, our default is also 10.
--
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
[jira] [Created] (TS-1928) False error / warning when setting log rotation size to exactly 10
Leif Hedstrom created TS-1928:
-
Summary: False error / warning when setting log rotation size to
exactly 10
Key: TS-1928
URL: https://issues.apache.org/jira/browse/TS-1928
Project: Traffic Server
Issue Type: Bug
Reporter: Leif Hedstrom
{code}
[May 29 14:52:50.402] Server {0x7f7e20191840} NOTE: Rolling size invalid(10)
for /opt/ats/var/log/trafficserver/squid.blog, setting it to 10 MB
{code}
As it turns out, our default is also 10.
--
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
[jira] [Resolved] (TS-1928) False error / warning when setting log rotation size to exactly 10
[
https://issues.apache.org/jira/browse/TS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom resolved TS-1928.
---
Resolution: Fixed
False error / warning when setting log rotation size to exactly 10
--
Key: TS-1928
URL: https://issues.apache.org/jira/browse/TS-1928
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 3.3.3
{code}
[May 29 14:52:50.402] Server {0x7f7e20191840} NOTE: Rolling size invalid(10)
for /opt/ats/var/log/trafficserver/squid.blog, setting it to 10 MB
{code}
As it turns out, our default is also 10.
--
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
[jira] [Commented] (TS-1928) False error / warning when setting log rotation size to exactly 10
[
https://issues.apache.org/jira/browse/TS-1928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669770#comment-13669770
]
ASF subversion and git services commented on TS-1928:
-
Commit 2592249e120ef8e20cbc998dbce845a53dadd509 in branch refs/heads/master
from [~zwoop]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=2592249 ]
TS-1928 False warning when setting log rotation size to exactly 10
False error / warning when setting log rotation size to exactly 10
--
Key: TS-1928
URL: https://issues.apache.org/jira/browse/TS-1928
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Leif Hedstrom
Assignee: Leif Hedstrom
Fix For: 3.3.3
{code}
[May 29 14:52:50.402] Server {0x7f7e20191840} NOTE: Rolling size invalid(10)
for /opt/ats/var/log/trafficserver/squid.blog, setting it to 10 MB
{code}
As it turns out, our default is also 10.
--
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
[jira] [Updated] (TS-1798) Crash report: UnixNetProcessor::connect_re_internal UnixNetProcessor::allocateThread
[
https://issues.apache.org/jira/browse/TS-1798?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1798:
--
Fix Version/s: (was: 3.3.3)
3.3.4
Crash report: UnixNetProcessor::connect_re_internal
UnixNetProcessor::allocateThread
---
Key: TS-1798
URL: https://issues.apache.org/jira/browse/TS-1798
Project: Traffic Server
Issue Type: Bug
Reporter: Zhao Yongming
Labels: crash
Fix For: 3.3.4
here is a stack which occured in the current master tree
{code}
[root@localhost trafficserver]# cat traffic.out
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0(+0xf500)[0x2afd236e5500]
/usr/bin/traffic_server(UnixNetProcessor::allocateThread(EThread*)+0x4)[0x66b404]
/usr/bin/traffic_server(UnixNetProcessor::connect_re_internal(Continuation*,
sockaddr const*, NetVCOptions*)+0x2e)[0x66c27e]
/usr/bin/traffic_server(HttpSM::do_http_server_open(bool)+0x6a8)[0x5287f8]
/usr/bin/traffic_server(HttpSM::set_next_state()+0x4dd)[0x52fbad]
/usr/bin/traffic_server(HttpSM::state_send_server_request_header(int,
void*)+0x84)[0x52ac94]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0xd8)[0x52c858]
/usr/bin/traffic_server[0x66ee21]
/usr/bin/traffic_server[0x6731b5]
/usr/bin/traffic_server(NetHandler::mainNetEvent(int, Event*)+0x1f2)[0x669ff2]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0x84)[0x694964]
/usr/bin/traffic_server(EThread::execute()+0x4b3)[0x695343]
/usr/bin/traffic_server[0x6938e2]
/lib64/libpthread.so.0(+0x7851)[0x2afd236dd851]
/lib64/libc.so.6(clone+0x6d)[0x2afd25d6f11d]
[TrafficServer] using root directory '/usr
{code}
--
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
[jira] [Updated] (TS-1711) Crash on NetHandler::mainNetEvent
[ https://issues.apache.org/jira/browse/TS-1711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1711: -- Fix Version/s: (was: 3.3.3) 3.3.4 Crash on NetHandler::mainNetEvent - Key: TS-1711 URL: https://issues.apache.org/jira/browse/TS-1711 Project: Traffic Server Issue Type: Bug Components: Clustering, Logging, Network Affects Versions: 3.2.4, 3.2.0 Reporter: Andrew Younan Fix For: 3.3.4 ATS 3.2.0 is installed on two RHEL6.2 nodes in cluster mode. IMHO, issue is not resolved in 3.2.4 as I can see. Two crashes are taking place: 1) One as described in Bug TS-1686 (https://issues.apache.org/jira/browse/TS-1686) and the other one below upon the mainNetEvent. For issue TS-1686, once logging was disabled the crashes did not reoccur. The below still occurs. Both are must fix. NOTE: Traffic Server received Sig 11: Segmentation fault /usr/bin/traffic_server - STACK TRACE: /lib64/libpthread.so.0[0x3caf80f4a0] /usr/bin/traffic_server[0x67697c] /usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x1f2)[0x66e0f2] /usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0xb4)[0x696d04] /usr/bin/traffic_server(_ZN7EThread7executeEv+0x4c3)[0x697693] /usr/bin/traffic_server[0x695cd2] /lib64/libpthread.so.0[0x3caf8077f1] /lib64/libc.so.6(clone+0x6d)[0x3caf4e570d] Coredump currently being analyzed (cannot be provided at the moment - 9GB); your assistance is urgently needed. Thanks, Andrew -- 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
[jira] [Commented] (TS-1590) use_remap_processor crashes if share_server_sessions = 2
[
https://issues.apache.org/jira/browse/TS-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669798#comment-13669798
]
Leif Hedstrom commented on TS-1590:
---
I suspect a refactoring of remap processor is required, to allow it to schedule
the appropriate events back to the calling ET_NET (net-thread). There's no
reason why the do_http_server_open() should have to happen on a remap thread.
You are definitely spot on, there is no l1_hash on the remap processor
threads... A real ugly solution would be to add that to them, but a better
solution is to change the remap processor to handle the continuation back to an
Net-thread before it needs the l1_hash.
I'm going to move this out to v3.5.0, unless I hear otherwise. I think it's
somewhat reasonable to say that you have to set share_server_sessions to 0 or 1
if you really have to use the remap processor (which I don't know of anyone
using).
use_remap_processor crashes if share_server_sessions = 2
Key: TS-1590
URL: https://issues.apache.org/jira/browse/TS-1590
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.3.0
Reporter: Conan Wang
Priority: Critical
Fix For: 3.3.3
easy to reproduce:
{code}
CONFIG proxy.config.remap.use_remap_processor INT 1 (default is 0)
CONFIG proxy.config.http.share_server_sessions INT 2 (0, 1 will be ok)
{code}
{code}
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x1210
[Switching to process 8927 thread 0x1a03]
0x0001000ead15 in _acquire_session (bucket=0x11c0, ip=0x6713138,
hostname_hash=@0xb06915d0, sm=0x6712aa0) at HttpSessionManager.cc:191
(gdb) bt
#0 0x0001000ead15 in _acquire_session (bucket=0x11c0, ip=0x6713138,
hostname_hash=@0xb06915d0, sm=0x6712aa0) at HttpSessionManager.cc:191
#1 0x0001000eb366 in HttpSessionManager::acquire_session
(this=0x100445e60, cont=0x6712aa0, ip=0x6713138, hostname=0x4ebc19
127.0.0.1, ua_session=0x2a88980, sm=0x6712aa0) at HttpSessionManager.cc:274
#2 0x000100105c29 in HttpSM::do_http_server_open (this=0x6712aa0,
raw=false) at HttpSM.cc:4384
..
(gdb) p this_ethread()-l1_hash
$2 = (SessionBucket *) 0x0
(gdb) p this_ethread()-event_types
$3 = 2 (ET_REMAP)
{code}
Using separate remap processor is a hidden option, and I enable it by
accident.. (Does anyone use it in prod?)
I noticed HttpSM::do_http_server_open is always executed by the remap
processer ethread (because of
action.continuation-handleEvent(EVENT_REMAP_COMPLETE, NULL), correct me if
wrong). While the remap thread was not initialized as ET_NET and has no
l1_hash, server session lookup in this ET_REMAP thread will crash.
I didn't find a quick way to make HttpSM handling EVENT_REMAP_COMPLETE on
ET_NET. So a fast workaround would be falling back to global server
connection when use_remap_processor.
--
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
[jira] [Updated] (TS-1590) use_remap_processor crashes if share_server_sessions = 2
[
https://issues.apache.org/jira/browse/TS-1590?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1590:
--
Fix Version/s: (was: 3.3.3)
3.5.0
use_remap_processor crashes if share_server_sessions = 2
Key: TS-1590
URL: https://issues.apache.org/jira/browse/TS-1590
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Affects Versions: 3.3.0
Reporter: Conan Wang
Priority: Critical
Fix For: 3.5.0
easy to reproduce:
{code}
CONFIG proxy.config.remap.use_remap_processor INT 1 (default is 0)
CONFIG proxy.config.http.share_server_sessions INT 2 (0, 1 will be ok)
{code}
{code}
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x1210
[Switching to process 8927 thread 0x1a03]
0x0001000ead15 in _acquire_session (bucket=0x11c0, ip=0x6713138,
hostname_hash=@0xb06915d0, sm=0x6712aa0) at HttpSessionManager.cc:191
(gdb) bt
#0 0x0001000ead15 in _acquire_session (bucket=0x11c0, ip=0x6713138,
hostname_hash=@0xb06915d0, sm=0x6712aa0) at HttpSessionManager.cc:191
#1 0x0001000eb366 in HttpSessionManager::acquire_session
(this=0x100445e60, cont=0x6712aa0, ip=0x6713138, hostname=0x4ebc19
127.0.0.1, ua_session=0x2a88980, sm=0x6712aa0) at HttpSessionManager.cc:274
#2 0x000100105c29 in HttpSM::do_http_server_open (this=0x6712aa0,
raw=false) at HttpSM.cc:4384
..
(gdb) p this_ethread()-l1_hash
$2 = (SessionBucket *) 0x0
(gdb) p this_ethread()-event_types
$3 = 2 (ET_REMAP)
{code}
Using separate remap processor is a hidden option, and I enable it by
accident.. (Does anyone use it in prod?)
I noticed HttpSM::do_http_server_open is always executed by the remap
processer ethread (because of
action.continuation-handleEvent(EVENT_REMAP_COMPLETE, NULL), correct me if
wrong). While the remap thread was not initialized as ET_NET and has no
l1_hash, server session lookup in this ET_REMAP thread will crash.
I didn't find a quick way to make HttpSM handling EVENT_REMAP_COMPLETE on
ET_NET. So a fast workaround would be falling back to global server
connection when use_remap_processor.
--
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
[jira] [Commented] (TS-1929) migrate admin and sdk docs to sphinx
[ https://issues.apache.org/jira/browse/TS-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669810#comment-13669810 ] James Peach commented on TS-1929: - Do we need to vote on this, or can I just merge Igor's branch? migrate admin and sdk docs to sphinx Key: TS-1929 URL: https://issues.apache.org/jira/browse/TS-1929 Project: Traffic Server Issue Type: Improvement Components: Documentation Reporter: James Peach We should migrate the admin guide and the SDK guide to the sphinx documentation processor. This would give us a more standard and widely known documentation format, the ability to keep documentation in the primary tree and the ability to integrate non-English translations. -- 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
[jira] [Created] (TS-1929) migrate admin and sdk docs to sphinx
James Peach created TS-1929: --- Summary: migrate admin and sdk docs to sphinx Key: TS-1929 URL: https://issues.apache.org/jira/browse/TS-1929 Project: Traffic Server Issue Type: Improvement Components: Documentation Reporter: James Peach We should migrate the admin guide and the SDK guide to the sphinx documentation processor. This would give us a more standard and widely known documentation format, the ability to keep documentation in the primary tree and the ability to integrate non-English translations. -- 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
[jira] [Commented] (TS-1757) core at LogUtils::escapify_url()
[
https://issues.apache.org/jira/browse/TS-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669814#comment-13669814
]
Leif Hedstrom commented on TS-1757:
---
I'm moving this out, until we have more details on this (e.g. how to reproduce).
core at LogUtils::escapify_url()
Key: TS-1757
URL: https://issues.apache.org/jira/browse/TS-1757
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Bin Chen
Assignee: taorui
Labels: crash
Fix For: 3.3.4
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x39ab20f4a0]
/usr/bin/traffic_server(LogUtils::escapify_url(Arena*, char*, unsigned long,
int*, char*, unsigned long, unsigned char const*)+0x60)[0x5b8550]
/usr/bin/traffic_server(LogAccessHttp::init()+0xbc)[0x59864c]
/usr/bin/traffic_server(Log::access(LogAccess*)+0x11e)[0x59b3ce]
/usr/bin/traffic_server(HttpSM::update_stats()+0x630)[0x52be20]
/usr/bin/traffic_server(HttpSM::kill_this()+0x928)[0x5374d8]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x5377f8]
/usr/bin/traffic_server[0x68727b]
/usr/bin/traffic_server(UnixNetVConnection::mainEvent(int,
Event*)+0x5df)[0x68989f]
/usr/bin/traffic_server(InactivityCop::check_inactivity(int,
Event*)+0xa6)[0x6839b6]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6ac714]
/usr/bin/traffic_server(PriorityEventQueue::check_ready(long,
EThread*)+0x17b)[0x6aebab]
/usr/bin/traffic_server(EThread::execute()+0x12c)[0x6acd0c]
/usr/bin/traffic_server[0x6ab2b2]
/lib64/libpthread.so.0[0x39ab2077f1]
/lib64/libc.so.6(clone+0x6d)[0x39aaee570d]
{code}
--
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
[jira] [Updated] (TS-1757) core at LogUtils::escapify_url()
[
https://issues.apache.org/jira/browse/TS-1757?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1757:
--
Fix Version/s: (was: 3.3.3)
3.3.4
core at LogUtils::escapify_url()
Key: TS-1757
URL: https://issues.apache.org/jira/browse/TS-1757
Project: Traffic Server
Issue Type: Bug
Components: Logging
Reporter: Bin Chen
Assignee: taorui
Labels: crash
Fix For: 3.3.4
{code}
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x39ab20f4a0]
/usr/bin/traffic_server(LogUtils::escapify_url(Arena*, char*, unsigned long,
int*, char*, unsigned long, unsigned char const*)+0x60)[0x5b8550]
/usr/bin/traffic_server(LogAccessHttp::init()+0xbc)[0x59864c]
/usr/bin/traffic_server(Log::access(LogAccess*)+0x11e)[0x59b3ce]
/usr/bin/traffic_server(HttpSM::update_stats()+0x630)[0x52be20]
/usr/bin/traffic_server(HttpSM::kill_this()+0x928)[0x5374d8]
/usr/bin/traffic_server(HttpSM::main_handler(int, void*)+0x198)[0x5377f8]
/usr/bin/traffic_server[0x68727b]
/usr/bin/traffic_server(UnixNetVConnection::mainEvent(int,
Event*)+0x5df)[0x68989f]
/usr/bin/traffic_server(InactivityCop::check_inactivity(int,
Event*)+0xa6)[0x6839b6]
/usr/bin/traffic_server(EThread::process_event(Event*, int)+0xb4)[0x6ac714]
/usr/bin/traffic_server(PriorityEventQueue::check_ready(long,
EThread*)+0x17b)[0x6aebab]
/usr/bin/traffic_server(EThread::execute()+0x12c)[0x6acd0c]
/usr/bin/traffic_server[0x6ab2b2]
/lib64/libpthread.so.0[0x39ab2077f1]
/lib64/libc.so.6(clone+0x6d)[0x39aaee570d]
{code}
--
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
[jira] [Commented] (TS-1921) reclaimable freelist stuck in infinite loop
[
https://issues.apache.org/jira/browse/TS-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669819#comment-13669819
]
James Peach commented on TS-1921:
-
I looked at the patch, can we just call ats_pagesize() when we need to? Is
there really a measurable benefit to caching that value in a static variable?
reclaimable freelist stuck in infinite loop
---
Key: TS-1921
URL: https://issues.apache.org/jira/browse/TS-1921
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
Attachments:
0001-Put-the-initialization-of-page_size-back-into-reclai.patch
{code}
flathead:build jpeach$ ./libtool --mode=execute lldb --
./proxy/traffic_server -R 1 -r SDK_API_TSNetVConn
Current executable set to '/Users/jpeach/build/proxy/.libs/traffic_server'
(x86_64).
...
(lldb) run
Process 65112 launched: '/Users/jpeach/build/proxy/.libs/traffic_server'
(x86_64)
...
Process 65112 stopped
* thread #1: tid = 0x1c03, 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150, stop
reason = signal SIGSTOP
frame #0: 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150
147if (chunk_size 1) {
148 /* make alignment to be (2^N * page_size),
149 * but not larger than MAX_CHUNK_BYTE_SIZE */
- 150 while (alignment chunk_byte_size)
151alignment = 1;
152}
153 }
(lldb) p alignment
(uint32_t) $0 = 0
(lldb) p chunk_byte_size
(uint32_t) $1 = 0
...
(lldb) bt
* thread #1: tid = 0x1c03, 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150, stop
reason = signal SIGSTOP
frame #0: 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150
frame #1: 0x000100c0094a
libtsutil.3.dylib`reclaimable_freelist_init(fl=0x000100c2fc18,
name=0x000100c1f0e0, type_size=1024, chunk_size=128, alignment=8) + 282
at ink_queue_ext.cc:471
frame #2: 0x000100bffec1
libtsutil.3.dylib`ink_freelist_init(fl=0x000100c2fc18,
name=0x000100c1f0e0, type_size=1024, chunk_size=128, alignment=8) + 49 at
ink_queue.cc:89
frame #3: 0x000100175621
traffic_server`Allocator::Allocator(this=0x000100c2fc18,
name=0x000100c1f0e0, element_size=1024, chunk_size=128, alignment=8) + 49
at Allocator.h:87
frame #4: 0x000100174e71
traffic_server`Allocator::Allocator(this=0x000100c2fc18,
name=0x000100c1f0e0, element_size=1024, chunk_size=128, alignment=8) + 49
at Allocator.h:88
frame #5: 0x000100bf3367 libtsutil.3.dylib`__cxx_global_var_init + 39
at Arena.cc:33
frame #6: 0x000100bf3379 libtsutil.3.dylib`_GLOBAL__I_a + 9 at
Arena.cc:88
frame #7: 0x7fff5fc13378
dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const) +
236
{code}
--
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
[jira] [Updated] (TS-1813) BACKPORT: TSTextLogObjects don't roll
[ https://issues.apache.org/jira/browse/TS-1813?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Peach updated TS-1813: Summary: BACKPORT: TSTextLogObjects don't roll (was: TSTextLogObjects don't roll, backport 3.2.x) BACKPORT: TSTextLogObjects don't roll - Key: TS-1813 URL: https://issues.apache.org/jira/browse/TS-1813 Project: Traffic Server Issue Type: Bug Components: Logging Reporter: Brian Geffon Assignee: Brian Geffon Fix For: 3.2.5 Attachments: LogObject.patch When you create a TextLogObject you're allowed to specify when the log will roll; however, trafficserver never actually rolls the log because it never enumerates the API Managed log objects when rolling. -- 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
[jira] [Commented] (TS-1824) TSHttpTxnPushedRespHdrBytesGet() probably shouldn't take an int *bytes parameter
[ https://issues.apache.org/jira/browse/TS-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669854#comment-13669854 ] Leif Hedstrom commented on TS-1824: --- Interesting, only the implementation is wrong, the prototype in ts/ts.h is correct. I'm making this change now. TSHttpTxnPushedRespHdrBytesGet() probably shouldn't take an int *bytes parameter Key: TS-1824 URL: https://issues.apache.org/jira/browse/TS-1824 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.3 I think this is a failed refactoring from the past, where TSHttpTxnPushedRespHdrBytesGet() was changed to return the int (bytes), but the input parameter was left. Changing this would break API / ABI compatibilities though :-/. -- 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
[jira] [Commented] (TS-1824) TSHttpTxnPushedRespHdrBytesGet() probably shouldn't take an int *bytes parameter
[ https://issues.apache.org/jira/browse/TS-1824?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669857#comment-13669857 ] ASF subversion and git services commented on TS-1824: - Commit f9cbfafd45f0980b1a123126102301c386af9fd7 in branch refs/heads/master from [~zwoop] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=f9cbfaf ] TS-1824 ] TSHttpTxnPushedRespHdrBytesGet() takes an int argument in the implementation, whereas the prototype does not have this. TSHttpTxnPushedRespHdrBytesGet() probably shouldn't take an int *bytes parameter Key: TS-1824 URL: https://issues.apache.org/jira/browse/TS-1824 Project: Traffic Server Issue Type: Improvement Components: TS API Reporter: Leif Hedstrom Assignee: Leif Hedstrom Fix For: 3.3.3 I think this is a failed refactoring from the past, where TSHttpTxnPushedRespHdrBytesGet() was changed to return the int (bytes), but the input parameter was left. Changing this would break API / ABI compatibilities though :-/. -- 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
[jira] [Commented] (TS-1660) Host field should not have c style terminator
[ https://issues.apache.org/jira/browse/TS-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669858#comment-13669858 ] Leif Hedstrom commented on TS-1660: --- Weijin: I still would like to understand this. If not, I'll probably back it out, and we can revisit later. Host field should not have c style terminator -- Key: TS-1660 URL: https://issues.apache.org/jira/browse/TS-1660 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: weijin Assignee: Leif Hedstrom Labels: A Fix For: 3.3.3 Attachments: ts-1660.diff if host field of client has c style terminator, it may lead to serious problems (e.g. ats use c string to do hostdb lookup). -- 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
[jira] [Updated] (TS-1660) Host field should not have c style terminator
[ https://issues.apache.org/jira/browse/TS-1660?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom updated TS-1660: -- Summary: Host field should not have c style terminator (was: Host field should not has c style terminator ) Host field should not have c style terminator -- Key: TS-1660 URL: https://issues.apache.org/jira/browse/TS-1660 Project: Traffic Server Issue Type: Bug Components: HTTP Reporter: weijin Assignee: Leif Hedstrom Labels: A Fix For: 3.3.3 Attachments: ts-1660.diff if host field of client has c style terminator, it may lead to serious problems (e.g. ats use c string to do hostdb lookup). -- 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
[jira] [Commented] (TS-1686) Crashed in LogUtils::remove_content_type_attributes
[
https://issues.apache.org/jira/browse/TS-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669859#comment-13669859
]
Leif Hedstrom commented on TS-1686:
---
Uri: I'm going to move this out to v3.3.5 for now, please move it back if
there's progress.
Crashed in LogUtils::remove_content_type_attributes
---
Key: TS-1686
URL: https://issues.apache.org/jira/browse/TS-1686
Project: Traffic Server
Issue Type: Bug
Components: Clustering, Logging
Reporter: Yunkai Zhang
Assignee: Uri Shachar
Fix For: 3.3.3
1) enable full cluster mode
2) two nodes in the cluster
3) use jtest tool to do pressure testing
{code}
[E. Mgmt] log == [TrafficManager] using root directory '/usr'
Layout configuration
--prefix = '/usr'
--exec_prefix = '/usr'
--bindir = '/usr/bin'
--sbindir = '/usr/sbin'
--sysconfdir = '/etc/trafficserver'
--datadir = '/usr/share/trafficserver'
--includedir = '/usr/include/trafficserver'
--libdir = '/usr/lib/trafficserver'
--libexecdir = '/usr/lib/trafficserver/plugins'
--localstatedir = '/var/trafficserver'
--runtimedir = '/var/run/trafficserver'
--logdir = '/var/log/trafficserver'
--mandir = '/usr/share/man'
--infodir = '/usr/share/info'
--cachedir = '/var/cache/trafficserver'
[TrafficServer] using root directory '/usr'
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x347380f4a0]
/lib64/libc.so.6(memchr+0x1b)[0x3473481bbb]
/usr/bin/traffic_server(_ZN8LogUtils30remove_content_type_attributesEPcPi+0x3d)[0x5fa51f]
/usr/bin/traffic_server(_ZN13LogAccessHttp4initEv+0x1dc)[0x5d35a2]
/usr/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x229)[0x5dc653]
/usr/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x204)[0x57a3b8]
/usr/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x336)[0x57a06c]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x35e)[0x56c6e0]
/usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x4e36f8]
/usr/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0x15d)[0x5b4563]
/usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x4e36f8]
/usr/bin/traffic_server[0x6c3275]
/usr/bin/traffic_server[0x6c33a5]
/usr/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x72d)[0x6c4383]
/usr/bin/traffic_server(_Z12write_to_netP10NetHandlerP18UnixNetVConnectionP14PollDescriptorP7EThread+0x84)[0x6c3c4f]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x716)[0x6bfff4]
/usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x4e36f8]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x120)[0x6e68f4]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x472)[0x6e6eec]
/usr/bin/traffic_server[0x6e5b00]
{code}
--
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
[jira] [Updated] (TS-1686) Crashed in LogUtils::remove_content_type_attributes
[
https://issues.apache.org/jira/browse/TS-1686?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom updated TS-1686:
--
Fix Version/s: (was: 3.3.3)
3.3.5
Crashed in LogUtils::remove_content_type_attributes
---
Key: TS-1686
URL: https://issues.apache.org/jira/browse/TS-1686
Project: Traffic Server
Issue Type: Bug
Components: Clustering, Logging
Reporter: Yunkai Zhang
Assignee: Uri Shachar
Fix For: 3.3.5
1) enable full cluster mode
2) two nodes in the cluster
3) use jtest tool to do pressure testing
{code}
[E. Mgmt] log == [TrafficManager] using root directory '/usr'
Layout configuration
--prefix = '/usr'
--exec_prefix = '/usr'
--bindir = '/usr/bin'
--sbindir = '/usr/sbin'
--sysconfdir = '/etc/trafficserver'
--datadir = '/usr/share/trafficserver'
--includedir = '/usr/include/trafficserver'
--libdir = '/usr/lib/trafficserver'
--libexecdir = '/usr/lib/trafficserver/plugins'
--localstatedir = '/var/trafficserver'
--runtimedir = '/var/run/trafficserver'
--logdir = '/var/log/trafficserver'
--mandir = '/usr/share/man'
--infodir = '/usr/share/info'
--cachedir = '/var/cache/trafficserver'
[TrafficServer] using root directory '/usr'
NOTE: Traffic Server received Sig 11: Segmentation fault
/usr/bin/traffic_server - STACK TRACE:
/lib64/libpthread.so.0[0x347380f4a0]
/lib64/libc.so.6(memchr+0x1b)[0x3473481bbb]
/usr/bin/traffic_server(_ZN8LogUtils30remove_content_type_attributesEPcPi+0x3d)[0x5fa51f]
/usr/bin/traffic_server(_ZN13LogAccessHttp4initEv+0x1dc)[0x5d35a2]
/usr/bin/traffic_server(_ZN3Log6accessEP9LogAccess+0x229)[0x5dc653]
/usr/bin/traffic_server(_ZN6HttpSM12update_statsEv+0x204)[0x57a3b8]
/usr/bin/traffic_server(_ZN6HttpSM9kill_thisEv+0x336)[0x57a06c]
/usr/bin/traffic_server(_ZN6HttpSM12main_handlerEiPv+0x35e)[0x56c6e0]
/usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x4e36f8]
/usr/bin/traffic_server(_ZN10HttpTunnel12main_handlerEiPv+0x15d)[0x5b4563]
/usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x4e36f8]
/usr/bin/traffic_server[0x6c3275]
/usr/bin/traffic_server[0x6c33a5]
/usr/bin/traffic_server(_Z15write_to_net_ioP10NetHandlerP18UnixNetVConnectionP7EThread+0x72d)[0x6c4383]
/usr/bin/traffic_server(_Z12write_to_netP10NetHandlerP18UnixNetVConnectionP14PollDescriptorP7EThread+0x84)[0x6c3c4f]
/usr/bin/traffic_server(_ZN10NetHandler12mainNetEventEiP5Event+0x716)[0x6bfff4]
/usr/bin/traffic_server(_ZN12Continuation11handleEventEiPv+0x6c)[0x4e36f8]
/usr/bin/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x120)[0x6e68f4]
/usr/bin/traffic_server(_ZN7EThread7executeEv+0x472)[0x6e6eec]
/usr/bin/traffic_server[0x6e5b00]
{code}
--
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
[jira] [Assigned] (TS-1492) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request)
[ https://issues.apache.org/jira/browse/TS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leif Hedstrom reassigned TS-1492: - Assignee: Leif Hedstrom (was: Bin Chen) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request) -- Key: TS-1492 URL: https://issues.apache.org/jira/browse/TS-1492 Project: Traffic Server Issue Type: Improvement Components: Core Affects Versions: 3.2.0 Reporter: Bin Chen Assignee: Leif Hedstrom Priority: Critical Labels: A Fix For: 3.3.3 Attachments: backdoor_not_throttling.patch In our env, ts will be throttled because of many request incomming simultaneously(because of frontend haproxy is restarted). But we don't expect ts be restarted because of this case. we can handled this: 1、if throttled, ts's health check request always be handled 2、many many connection request may be handled in long time -- 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
[jira] [Commented] (TS-1492) if being net_connections_throttled, ts must to be restarted?(because of can't accept health checking request)
[
https://issues.apache.org/jira/browse/TS-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669876#comment-13669876
]
Leif Hedstrom commented on TS-1492:
---
James, so, looking at the code, I do agree that backdoor is somewhat
unfortunate, something like from_cop would be better. However, the notion of
backdoor is all over the code, and is bridged across API boundaries via
{code}
na-backdoor = opt.backdoor;
{code}
My vote would be that we keep the name backdoor for now, and file a separate
bug to rename this to something else. The name allow_throttle has some
weirdness to it, it's somewhat the inverse of what backdoor means, but if you
feel strongly about that, I don't really care that much. The bridge would
then be e.g.
{code}
na-allow_throttle = !opt.backdoor;
{code}
and we change the code in this patch to invert the logic as well.
if being net_connections_throttled, ts must to be restarted?(because of
can't accept health checking request)
--
Key: TS-1492
URL: https://issues.apache.org/jira/browse/TS-1492
Project: Traffic Server
Issue Type: Improvement
Components: Core
Affects Versions: 3.2.0
Reporter: Bin Chen
Assignee: Leif Hedstrom
Priority: Critical
Labels: A
Fix For: 3.3.3
Attachments: backdoor_not_throttling.patch
In our env, ts will be throttled because of many request incomming
simultaneously(because of frontend haproxy is restarted). But we don't expect
ts be restarted because of this case. we can handled this:
1、if throttled, ts's health check request always be handled
2、many many connection request may be handled in long time
--
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
[jira] [Commented] (TS-1648) Segmentation fault in dir_clear_range()
[
https://issues.apache.org/jira/browse/TS-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669893#comment-13669893
]
John Plevyak commented on TS-1648:
--
Rather than long we should be using int64 as long is not well defined (it is
platform dependent). Are those 10TB RAIDs? If so, you are better of using them
as JBOD since ATS assumes that there is a single disk arm (or equal fraction)
for each disk is storage.config. Because of the size of your disk it is
possible that you have more than 2^31 directory entries which would account for
the overflow. Also, given the size, the clear may take a long time. Your
trace is not long enough for me to see if it repeats. However, if it does
repeat, it is possible that it is because dir_in_bucket also takes an int which
is then multiplied to get a directory number. The other possibility is (of
course) that you have memory corruption: the directory is the single largest
memory user, and it contains a linked list which can be circularized by
corruption, but let's concentrate on the other issues first.
I would suggest that we change all the bucket/entry/etc offsets to int64 (I can
build a patch, but I would appreciate a review). Second, I would suggest
(after testing to ensure that the patch fixes your problem) that you move to
JBOD rather than RAID-0 or to having multiple NAS volumes which correspond
approximately to the number of underlying disks since ATS will only have one
outstanding write (although multiple reads) for each disk in storage.config.
Segmentation fault in dir_clear_range()
---
Key: TS-1648
URL: https://issues.apache.org/jira/browse/TS-1648
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 3.3.0, 3.2.0
Environment: reverse proxy
Reporter: Tomasz Kuzemko
Assignee: weijin
Labels: A
Fix For: 3.3.3
Attachments:
0001-Fix-for-TS-1648-Segmentation-fault-in-dir_clear_rang.patch
I use ATS as a reverse proxy. I have a fairly large disk cache consisting of
2x 10TB raw disks. I do not use cache compression. After a few days of
running (this is a dev machine - not handling any traffic) ATS begins to
crash with a segfault shortly after start:
[Jan 11 16:11:00.690] Server {0x72bb8700} DEBUG: (rusage) took rusage
snap 1357917060690487000
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x720ad700 (LWP 17292)]
0x00696a71 in dir_clear_range (start=640, end=17024, vol=0x16057d0)
at CacheDir.cc:382
382 CacheDir.cc: No such file or directory.
in CacheDir.cc
(gdb) p i
$1 = 214748365
(gdb) l
377 in CacheDir.cc
(gdb) p dir_index(vol, i)
$2 = (Dir *) 0x7ff997a04002
(gdb) p dir_index(vol, i-1)
$3 = (Dir *) 0x7ffa97a03ff8
(gdb) p *dir_index(vol, i-1)
$4 = {w = {0, 0, 0, 0, 0}}
(gdb) p *dir_index(vol, i-2)
$5 = {w = {0, 0, 52431, 52423, 0}}
(gdb) p *dir_index(vol, i)
Cannot access memory at address 0x7ff997a04002
(gdb) p *dir_index(vol, i+2)
Cannot access memory at address 0x7ff997a04016
(gdb) p *dir_index(vol, i+1)
Cannot access memory at address 0x7ff997a0400c
(gdb) p vol-buckets * DIR_DEPTH * vol-segments
$6 = 1246953472
(gdb) bt
#0 0x00696a71 in dir_clear_range (start=640, end=17024,
vol=0x16057d0) at CacheDir.cc:382
#1 0x0068aba2 in Vol::handle_recover_from_data (this=0x16057d0,
event=3900, data=0x16058a0) at Cache.cc:1384
#2 0x004e8e1c in Continuation::handleEvent (this=0x16057d0,
event=3900, data=0x16058a0) at ../iocore/eventsystem/I_Continuation.h:146
#3 0x00692385 in AIOCallbackInternal::io_complete (this=0x16058a0,
event=1, data=0x135afc0) at ../../iocore/aio/P_AIO.h:80
#4 0x004e8e1c in Continuation::handleEvent (this=0x16058a0, event=1,
data=0x135afc0) at ../iocore/eventsystem/I_Continuation.h:146
#5 0x00700fec in EThread::process_event (this=0x736c4010,
e=0x135afc0, calling_code=1) at UnixEThread.cc:142
#6 0x007011ff in EThread::execute (this=0x736c4010) at
UnixEThread.cc:191
#7 0x006ff8c2 in spawn_thread_internal (a=0x1356040) at Thread.cc:88
#8 0x7797e8ca in start_thread () from /lib/libpthread.so.0
#9 0x755c6b6d in clone () from /lib/libc.so.6
#10 0x in ?? ()
This is fixed by running traffic_server -Kk to clear the cache. But after a
few days the issue reappears.
I will keep the current faulty setup as-is in case you need me to provide
more data. I tried to make a core dump but it took a couple of GB even after
gzip (I can however provide it on request).
*Edit*
OS is Debian GNU/Linux 6.0.6 with custom built kernel
3.2.13-grsec--grs-ipv6-64
--
This message is automatically generated by JIRA.
[jira] [Commented] (TS-1648) Segmentation fault in dir_clear_range()
[
https://issues.apache.org/jira/browse/TS-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13669939#comment-13669939
]
Leif Hedstrom commented on TS-1648:
---
+1 on the proposal to change types to use e.g. int64_t / uint64_t consistently.
I'd be happy to review and test some patches. John, I'm assigning this bug to
you, thanks!
Segmentation fault in dir_clear_range()
---
Key: TS-1648
URL: https://issues.apache.org/jira/browse/TS-1648
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 3.3.0, 3.2.0
Environment: reverse proxy
Reporter: Tomasz Kuzemko
Assignee: weijin
Labels: A
Fix For: 3.3.3
Attachments:
0001-Fix-for-TS-1648-Segmentation-fault-in-dir_clear_rang.patch
I use ATS as a reverse proxy. I have a fairly large disk cache consisting of
2x 10TB raw disks. I do not use cache compression. After a few days of
running (this is a dev machine - not handling any traffic) ATS begins to
crash with a segfault shortly after start:
[Jan 11 16:11:00.690] Server {0x72bb8700} DEBUG: (rusage) took rusage
snap 1357917060690487000
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x720ad700 (LWP 17292)]
0x00696a71 in dir_clear_range (start=640, end=17024, vol=0x16057d0)
at CacheDir.cc:382
382 CacheDir.cc: No such file or directory.
in CacheDir.cc
(gdb) p i
$1 = 214748365
(gdb) l
377 in CacheDir.cc
(gdb) p dir_index(vol, i)
$2 = (Dir *) 0x7ff997a04002
(gdb) p dir_index(vol, i-1)
$3 = (Dir *) 0x7ffa97a03ff8
(gdb) p *dir_index(vol, i-1)
$4 = {w = {0, 0, 0, 0, 0}}
(gdb) p *dir_index(vol, i-2)
$5 = {w = {0, 0, 52431, 52423, 0}}
(gdb) p *dir_index(vol, i)
Cannot access memory at address 0x7ff997a04002
(gdb) p *dir_index(vol, i+2)
Cannot access memory at address 0x7ff997a04016
(gdb) p *dir_index(vol, i+1)
Cannot access memory at address 0x7ff997a0400c
(gdb) p vol-buckets * DIR_DEPTH * vol-segments
$6 = 1246953472
(gdb) bt
#0 0x00696a71 in dir_clear_range (start=640, end=17024,
vol=0x16057d0) at CacheDir.cc:382
#1 0x0068aba2 in Vol::handle_recover_from_data (this=0x16057d0,
event=3900, data=0x16058a0) at Cache.cc:1384
#2 0x004e8e1c in Continuation::handleEvent (this=0x16057d0,
event=3900, data=0x16058a0) at ../iocore/eventsystem/I_Continuation.h:146
#3 0x00692385 in AIOCallbackInternal::io_complete (this=0x16058a0,
event=1, data=0x135afc0) at ../../iocore/aio/P_AIO.h:80
#4 0x004e8e1c in Continuation::handleEvent (this=0x16058a0, event=1,
data=0x135afc0) at ../iocore/eventsystem/I_Continuation.h:146
#5 0x00700fec in EThread::process_event (this=0x736c4010,
e=0x135afc0, calling_code=1) at UnixEThread.cc:142
#6 0x007011ff in EThread::execute (this=0x736c4010) at
UnixEThread.cc:191
#7 0x006ff8c2 in spawn_thread_internal (a=0x1356040) at Thread.cc:88
#8 0x7797e8ca in start_thread () from /lib/libpthread.so.0
#9 0x755c6b6d in clone () from /lib/libc.so.6
#10 0x in ?? ()
This is fixed by running traffic_server -Kk to clear the cache. But after a
few days the issue reappears.
I will keep the current faulty setup as-is in case you need me to provide
more data. I tried to make a core dump but it took a couple of GB even after
gzip (I can however provide it on request).
*Edit*
OS is Debian GNU/Linux 6.0.6 with custom built kernel
3.2.13-grsec--grs-ipv6-64
--
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
[jira] [Assigned] (TS-1648) Segmentation fault in dir_clear_range()
[
https://issues.apache.org/jira/browse/TS-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leif Hedstrom reassigned TS-1648:
-
Assignee: John Plevyak (was: weijin)
Segmentation fault in dir_clear_range()
---
Key: TS-1648
URL: https://issues.apache.org/jira/browse/TS-1648
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 3.3.0, 3.2.0
Environment: reverse proxy
Reporter: Tomasz Kuzemko
Assignee: John Plevyak
Labels: A
Fix For: 3.3.3
Attachments:
0001-Fix-for-TS-1648-Segmentation-fault-in-dir_clear_rang.patch
I use ATS as a reverse proxy. I have a fairly large disk cache consisting of
2x 10TB raw disks. I do not use cache compression. After a few days of
running (this is a dev machine - not handling any traffic) ATS begins to
crash with a segfault shortly after start:
[Jan 11 16:11:00.690] Server {0x72bb8700} DEBUG: (rusage) took rusage
snap 1357917060690487000
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x720ad700 (LWP 17292)]
0x00696a71 in dir_clear_range (start=640, end=17024, vol=0x16057d0)
at CacheDir.cc:382
382 CacheDir.cc: No such file or directory.
in CacheDir.cc
(gdb) p i
$1 = 214748365
(gdb) l
377 in CacheDir.cc
(gdb) p dir_index(vol, i)
$2 = (Dir *) 0x7ff997a04002
(gdb) p dir_index(vol, i-1)
$3 = (Dir *) 0x7ffa97a03ff8
(gdb) p *dir_index(vol, i-1)
$4 = {w = {0, 0, 0, 0, 0}}
(gdb) p *dir_index(vol, i-2)
$5 = {w = {0, 0, 52431, 52423, 0}}
(gdb) p *dir_index(vol, i)
Cannot access memory at address 0x7ff997a04002
(gdb) p *dir_index(vol, i+2)
Cannot access memory at address 0x7ff997a04016
(gdb) p *dir_index(vol, i+1)
Cannot access memory at address 0x7ff997a0400c
(gdb) p vol-buckets * DIR_DEPTH * vol-segments
$6 = 1246953472
(gdb) bt
#0 0x00696a71 in dir_clear_range (start=640, end=17024,
vol=0x16057d0) at CacheDir.cc:382
#1 0x0068aba2 in Vol::handle_recover_from_data (this=0x16057d0,
event=3900, data=0x16058a0) at Cache.cc:1384
#2 0x004e8e1c in Continuation::handleEvent (this=0x16057d0,
event=3900, data=0x16058a0) at ../iocore/eventsystem/I_Continuation.h:146
#3 0x00692385 in AIOCallbackInternal::io_complete (this=0x16058a0,
event=1, data=0x135afc0) at ../../iocore/aio/P_AIO.h:80
#4 0x004e8e1c in Continuation::handleEvent (this=0x16058a0, event=1,
data=0x135afc0) at ../iocore/eventsystem/I_Continuation.h:146
#5 0x00700fec in EThread::process_event (this=0x736c4010,
e=0x135afc0, calling_code=1) at UnixEThread.cc:142
#6 0x007011ff in EThread::execute (this=0x736c4010) at
UnixEThread.cc:191
#7 0x006ff8c2 in spawn_thread_internal (a=0x1356040) at Thread.cc:88
#8 0x7797e8ca in start_thread () from /lib/libpthread.so.0
#9 0x755c6b6d in clone () from /lib/libc.so.6
#10 0x in ?? ()
This is fixed by running traffic_server -Kk to clear the cache. But after a
few days the issue reappears.
I will keep the current faulty setup as-is in case you need me to provide
more data. I tried to make a core dump but it took a couple of GB even after
gzip (I can however provide it on request).
*Edit*
OS is Debian GNU/Linux 6.0.6 with custom built kernel
3.2.13-grsec--grs-ipv6-64
--
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
[jira] [Commented] (TS-1648) Segmentation fault in dir_clear_range()
[
https://issues.apache.org/jira/browse/TS-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13670005#comment-13670005
]
John Plevyak commented on TS-1648:
--
I added a patch to make the variables I think are causing the problem int64_t.
Segmentation fault in dir_clear_range()
---
Key: TS-1648
URL: https://issues.apache.org/jira/browse/TS-1648
Project: Traffic Server
Issue Type: Bug
Components: Cache
Affects Versions: 3.3.0, 3.2.0
Environment: reverse proxy
Reporter: Tomasz Kuzemko
Assignee: John Plevyak
Labels: A
Fix For: 3.3.3
Attachments:
0001-Fix-for-TS-1648-Segmentation-fault-in-dir_clear_rang.patch,
cachedir_int64-jp-1.patch
I use ATS as a reverse proxy. I have a fairly large disk cache consisting of
2x 10TB raw disks. I do not use cache compression. After a few days of
running (this is a dev machine - not handling any traffic) ATS begins to
crash with a segfault shortly after start:
[Jan 11 16:11:00.690] Server {0x72bb8700} DEBUG: (rusage) took rusage
snap 1357917060690487000
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x720ad700 (LWP 17292)]
0x00696a71 in dir_clear_range (start=640, end=17024, vol=0x16057d0)
at CacheDir.cc:382
382 CacheDir.cc: No such file or directory.
in CacheDir.cc
(gdb) p i
$1 = 214748365
(gdb) l
377 in CacheDir.cc
(gdb) p dir_index(vol, i)
$2 = (Dir *) 0x7ff997a04002
(gdb) p dir_index(vol, i-1)
$3 = (Dir *) 0x7ffa97a03ff8
(gdb) p *dir_index(vol, i-1)
$4 = {w = {0, 0, 0, 0, 0}}
(gdb) p *dir_index(vol, i-2)
$5 = {w = {0, 0, 52431, 52423, 0}}
(gdb) p *dir_index(vol, i)
Cannot access memory at address 0x7ff997a04002
(gdb) p *dir_index(vol, i+2)
Cannot access memory at address 0x7ff997a04016
(gdb) p *dir_index(vol, i+1)
Cannot access memory at address 0x7ff997a0400c
(gdb) p vol-buckets * DIR_DEPTH * vol-segments
$6 = 1246953472
(gdb) bt
#0 0x00696a71 in dir_clear_range (start=640, end=17024,
vol=0x16057d0) at CacheDir.cc:382
#1 0x0068aba2 in Vol::handle_recover_from_data (this=0x16057d0,
event=3900, data=0x16058a0) at Cache.cc:1384
#2 0x004e8e1c in Continuation::handleEvent (this=0x16057d0,
event=3900, data=0x16058a0) at ../iocore/eventsystem/I_Continuation.h:146
#3 0x00692385 in AIOCallbackInternal::io_complete (this=0x16058a0,
event=1, data=0x135afc0) at ../../iocore/aio/P_AIO.h:80
#4 0x004e8e1c in Continuation::handleEvent (this=0x16058a0, event=1,
data=0x135afc0) at ../iocore/eventsystem/I_Continuation.h:146
#5 0x00700fec in EThread::process_event (this=0x736c4010,
e=0x135afc0, calling_code=1) at UnixEThread.cc:142
#6 0x007011ff in EThread::execute (this=0x736c4010) at
UnixEThread.cc:191
#7 0x006ff8c2 in spawn_thread_internal (a=0x1356040) at Thread.cc:88
#8 0x7797e8ca in start_thread () from /lib/libpthread.so.0
#9 0x755c6b6d in clone () from /lib/libc.so.6
#10 0x in ?? ()
This is fixed by running traffic_server -Kk to clear the cache. But after a
few days the issue reappears.
I will keep the current faulty setup as-is in case you need me to provide
more data. I tried to make a core dump but it took a couple of GB even after
gzip (I can however provide it on request).
*Edit*
OS is Debian GNU/Linux 6.0.6 with custom built kernel
3.2.13-grsec--grs-ipv6-64
--
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
[jira] [Commented] (TS-1921) reclaimable freelist stuck in infinite loop
[
https://issues.apache.org/jira/browse/TS-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13670006#comment-13670006
]
Yunkai Zhang commented on TS-1921:
--
In reclaimable-freelist, the page_size variable would be used in mmap_align()
which is called by ink_chunk_create().
When ATS reboot, ink_chunk_create() will be called frequently to allocate
buffer memory.
I can't figure out how much benefit we can get, but if a static variable can
help us to improve, why not?
reclaimable freelist stuck in infinite loop
---
Key: TS-1921
URL: https://issues.apache.org/jira/browse/TS-1921
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
Attachments:
0001-Put-the-initialization-of-page_size-back-into-reclai.patch
{code}
flathead:build jpeach$ ./libtool --mode=execute lldb --
./proxy/traffic_server -R 1 -r SDK_API_TSNetVConn
Current executable set to '/Users/jpeach/build/proxy/.libs/traffic_server'
(x86_64).
...
(lldb) run
Process 65112 launched: '/Users/jpeach/build/proxy/.libs/traffic_server'
(x86_64)
...
Process 65112 stopped
* thread #1: tid = 0x1c03, 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150, stop
reason = signal SIGSTOP
frame #0: 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150
147if (chunk_size 1) {
148 /* make alignment to be (2^N * page_size),
149 * but not larger than MAX_CHUNK_BYTE_SIZE */
- 150 while (alignment chunk_byte_size)
151alignment = 1;
152}
153 }
(lldb) p alignment
(uint32_t) $0 = 0
(lldb) p chunk_byte_size
(uint32_t) $1 = 0
...
(lldb) bt
* thread #1: tid = 0x1c03, 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150, stop
reason = signal SIGSTOP
frame #0: 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150
frame #1: 0x000100c0094a
libtsutil.3.dylib`reclaimable_freelist_init(fl=0x000100c2fc18,
name=0x000100c1f0e0, type_size=1024, chunk_size=128, alignment=8) + 282
at ink_queue_ext.cc:471
frame #2: 0x000100bffec1
libtsutil.3.dylib`ink_freelist_init(fl=0x000100c2fc18,
name=0x000100c1f0e0, type_size=1024, chunk_size=128, alignment=8) + 49 at
ink_queue.cc:89
frame #3: 0x000100175621
traffic_server`Allocator::Allocator(this=0x000100c2fc18,
name=0x000100c1f0e0, element_size=1024, chunk_size=128, alignment=8) + 49
at Allocator.h:87
frame #4: 0x000100174e71
traffic_server`Allocator::Allocator(this=0x000100c2fc18,
name=0x000100c1f0e0, element_size=1024, chunk_size=128, alignment=8) + 49
at Allocator.h:88
frame #5: 0x000100bf3367 libtsutil.3.dylib`__cxx_global_var_init + 39
at Arena.cc:33
frame #6: 0x000100bf3379 libtsutil.3.dylib`_GLOBAL__I_a + 9 at
Arena.cc:88
frame #7: 0x7fff5fc13378
dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const) +
236
{code}
--
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
[jira] [Commented] (TS-1921) reclaimable freelist stuck in infinite loop
[
https://issues.apache.org/jira/browse/TS-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13670024#comment-13670024
]
James Peach commented on TS-1921:
-
If keeping a static cache is a performance win, then let's do that in
{{ats_pagesize()}} so every code can benefit. If not, then using a local static
makes the code more fragile, as evidenced by this bug ;)
reclaimable freelist stuck in infinite loop
---
Key: TS-1921
URL: https://issues.apache.org/jira/browse/TS-1921
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
Attachments:
0001-Put-the-initialization-of-page_size-back-into-reclai.patch
{code}
flathead:build jpeach$ ./libtool --mode=execute lldb --
./proxy/traffic_server -R 1 -r SDK_API_TSNetVConn
Current executable set to '/Users/jpeach/build/proxy/.libs/traffic_server'
(x86_64).
...
(lldb) run
Process 65112 launched: '/Users/jpeach/build/proxy/.libs/traffic_server'
(x86_64)
...
Process 65112 stopped
* thread #1: tid = 0x1c03, 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150, stop
reason = signal SIGSTOP
frame #0: 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150
147if (chunk_size 1) {
148 /* make alignment to be (2^N * page_size),
149 * but not larger than MAX_CHUNK_BYTE_SIZE */
- 150 while (alignment chunk_byte_size)
151alignment = 1;
152}
153 }
(lldb) p alignment
(uint32_t) $0 = 0
(lldb) p chunk_byte_size
(uint32_t) $1 = 0
...
(lldb) bt
* thread #1: tid = 0x1c03, 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150, stop
reason = signal SIGSTOP
frame #0: 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150
frame #1: 0x000100c0094a
libtsutil.3.dylib`reclaimable_freelist_init(fl=0x000100c2fc18,
name=0x000100c1f0e0, type_size=1024, chunk_size=128, alignment=8) + 282
at ink_queue_ext.cc:471
frame #2: 0x000100bffec1
libtsutil.3.dylib`ink_freelist_init(fl=0x000100c2fc18,
name=0x000100c1f0e0, type_size=1024, chunk_size=128, alignment=8) + 49 at
ink_queue.cc:89
frame #3: 0x000100175621
traffic_server`Allocator::Allocator(this=0x000100c2fc18,
name=0x000100c1f0e0, element_size=1024, chunk_size=128, alignment=8) + 49
at Allocator.h:87
frame #4: 0x000100174e71
traffic_server`Allocator::Allocator(this=0x000100c2fc18,
name=0x000100c1f0e0, element_size=1024, chunk_size=128, alignment=8) + 49
at Allocator.h:88
frame #5: 0x000100bf3367 libtsutil.3.dylib`__cxx_global_var_init + 39
at Arena.cc:33
frame #6: 0x000100bf3379 libtsutil.3.dylib`_GLOBAL__I_a + 9 at
Arena.cc:88
frame #7: 0x7fff5fc13378
dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const) +
236
{code}
--
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
[jira] [Updated] (TS-1648) Segmentation fault in dir_clear_range()
[
https://issues.apache.org/jira/browse/TS-1648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James Peach updated TS-1648:
Description:
I use ATS as a reverse proxy. I have a fairly large disk cache consisting of 2x
10TB raw disks. I do not use cache compression. After a few days of running
(this is a dev machine - not handling any traffic) ATS begins to crash with a
segfault shortly after start:
{code}
[Jan 11 16:11:00.690] Server {0x72bb8700} DEBUG: (rusage) took rusage snap
1357917060690487000
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x720ad700 (LWP 17292)]
0x00696a71 in dir_clear_range (start=640, end=17024, vol=0x16057d0) at
CacheDir.cc:382
382 CacheDir.cc: No such file or directory.
in CacheDir.cc
(gdb) p i
$1 = 214748365
(gdb) l
377 in CacheDir.cc
(gdb) p dir_index(vol, i)
$2 = (Dir *) 0x7ff997a04002
(gdb) p dir_index(vol, i-1)
$3 = (Dir *) 0x7ffa97a03ff8
(gdb) p *dir_index(vol, i-1)
$4 = {w = {0, 0, 0, 0, 0}}
(gdb) p *dir_index(vol, i-2)
$5 = {w = {0, 0, 52431, 52423, 0}}
(gdb) p *dir_index(vol, i)
Cannot access memory at address 0x7ff997a04002
(gdb) p *dir_index(vol, i+2)
Cannot access memory at address 0x7ff997a04016
(gdb) p *dir_index(vol, i+1)
Cannot access memory at address 0x7ff997a0400c
(gdb) p vol-buckets * DIR_DEPTH * vol-segments
$6 = 1246953472
(gdb) bt
#0 0x00696a71 in dir_clear_range (start=640, end=17024, vol=0x16057d0)
at CacheDir.cc:382
#1 0x0068aba2 in Vol::handle_recover_from_data (this=0x16057d0,
event=3900, data=0x16058a0) at Cache.cc:1384
#2 0x004e8e1c in Continuation::handleEvent (this=0x16057d0,
event=3900, data=0x16058a0) at ../iocore/eventsystem/I_Continuation.h:146
#3 0x00692385 in AIOCallbackInternal::io_complete (this=0x16058a0,
event=1, data=0x135afc0) at ../../iocore/aio/P_AIO.h:80
#4 0x004e8e1c in Continuation::handleEvent (this=0x16058a0, event=1,
data=0x135afc0) at ../iocore/eventsystem/I_Continuation.h:146
#5 0x00700fec in EThread::process_event (this=0x736c4010,
e=0x135afc0, calling_code=1) at UnixEThread.cc:142
#6 0x007011ff in EThread::execute (this=0x736c4010) at
UnixEThread.cc:191
#7 0x006ff8c2 in spawn_thread_internal (a=0x1356040) at Thread.cc:88
#8 0x7797e8ca in start_thread () from /lib/libpthread.so.0
#9 0x755c6b6d in clone () from /lib/libc.so.6
#10 0x in ?? ()
{code}
This is fixed by running traffic_server -Kk to clear the cache. But after a
few days the issue reappears.
I will keep the current faulty setup as-is in case you need me to provide more
data. I tried to make a core dump but it took a couple of GB even after gzip (I
can however provide it on request).
*Edit*
OS is Debian GNU/Linux 6.0.6 with custom built kernel
3.2.13-grsec--grs-ipv6-64
was:
I use ATS as a reverse proxy. I have a fairly large disk cache consisting of 2x
10TB raw disks. I do not use cache compression. After a few days of running
(this is a dev machine - not handling any traffic) ATS begins to crash with a
segfault shortly after start:
[Jan 11 16:11:00.690] Server {0x72bb8700} DEBUG: (rusage) took rusage snap
1357917060690487000
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x720ad700 (LWP 17292)]
0x00696a71 in dir_clear_range (start=640, end=17024, vol=0x16057d0) at
CacheDir.cc:382
382 CacheDir.cc: No such file or directory.
in CacheDir.cc
(gdb) p i
$1 = 214748365
(gdb) l
377 in CacheDir.cc
(gdb) p dir_index(vol, i)
$2 = (Dir *) 0x7ff997a04002
(gdb) p dir_index(vol, i-1)
$3 = (Dir *) 0x7ffa97a03ff8
(gdb) p *dir_index(vol, i-1)
$4 = {w = {0, 0, 0, 0, 0}}
(gdb) p *dir_index(vol, i-2)
$5 = {w = {0, 0, 52431, 52423, 0}}
(gdb) p *dir_index(vol, i)
Cannot access memory at address 0x7ff997a04002
(gdb) p *dir_index(vol, i+2)
Cannot access memory at address 0x7ff997a04016
(gdb) p *dir_index(vol, i+1)
Cannot access memory at address 0x7ff997a0400c
(gdb) p vol-buckets * DIR_DEPTH * vol-segments
$6 = 1246953472
(gdb) bt
#0 0x00696a71 in dir_clear_range (start=640, end=17024, vol=0x16057d0)
at CacheDir.cc:382
#1 0x0068aba2 in Vol::handle_recover_from_data (this=0x16057d0,
event=3900, data=0x16058a0) at Cache.cc:1384
#2 0x004e8e1c in Continuation::handleEvent (this=0x16057d0,
event=3900, data=0x16058a0) at ../iocore/eventsystem/I_Continuation.h:146
#3 0x00692385 in AIOCallbackInternal::io_complete (this=0x16058a0,
event=1, data=0x135afc0) at ../../iocore/aio/P_AIO.h:80
#4 0x004e8e1c in Continuation::handleEvent (this=0x16058a0, event=1,
data=0x135afc0) at ../iocore/eventsystem/I_Continuation.h:146
#5 0x00700fec in EThread::process_event (this=0x736c4010,
e=0x135afc0, calling_code=1) at UnixEThread.cc:142
#6 0x007011ff in EThread::execute (this=0x736c4010) at
UnixEThread.cc:191
[jira] [Commented] (TS-1921) reclaimable freelist stuck in infinite loop
[
https://issues.apache.org/jira/browse/TS-1921?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13670059#comment-13670059
]
Yunkai Zhang commented on TS-1921:
--
It's a good idea.
reclaimable freelist stuck in infinite loop
---
Key: TS-1921
URL: https://issues.apache.org/jira/browse/TS-1921
Project: Traffic Server
Issue Type: Bug
Components: Core
Reporter: James Peach
Attachments:
0001-Put-the-initialization-of-page_size-back-into-reclai.patch
{code}
flathead:build jpeach$ ./libtool --mode=execute lldb --
./proxy/traffic_server -R 1 -r SDK_API_TSNetVConn
Current executable set to '/Users/jpeach/build/proxy/.libs/traffic_server'
(x86_64).
...
(lldb) run
Process 65112 launched: '/Users/jpeach/build/proxy/.libs/traffic_server'
(x86_64)
...
Process 65112 stopped
* thread #1: tid = 0x1c03, 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150, stop
reason = signal SIGSTOP
frame #0: 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150
147if (chunk_size 1) {
148 /* make alignment to be (2^N * page_size),
149 * but not larger than MAX_CHUNK_BYTE_SIZE */
- 150 while (alignment chunk_byte_size)
151alignment = 1;
152}
153 }
(lldb) p alignment
(uint32_t) $0 = 0
(lldb) p chunk_byte_size
(uint32_t) $1 = 0
...
(lldb) bt
* thread #1: tid = 0x1c03, 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150, stop
reason = signal SIGSTOP
frame #0: 0x000100c00b51
libtsutil.3.dylib`memory_alignment_init(f=0x000101007040, type_size=1024,
chunk_size=4294967295, alignment=0) + 401 at ink_queue_ext.cc:150
frame #1: 0x000100c0094a
libtsutil.3.dylib`reclaimable_freelist_init(fl=0x000100c2fc18,
name=0x000100c1f0e0, type_size=1024, chunk_size=128, alignment=8) + 282
at ink_queue_ext.cc:471
frame #2: 0x000100bffec1
libtsutil.3.dylib`ink_freelist_init(fl=0x000100c2fc18,
name=0x000100c1f0e0, type_size=1024, chunk_size=128, alignment=8) + 49 at
ink_queue.cc:89
frame #3: 0x000100175621
traffic_server`Allocator::Allocator(this=0x000100c2fc18,
name=0x000100c1f0e0, element_size=1024, chunk_size=128, alignment=8) + 49
at Allocator.h:87
frame #4: 0x000100174e71
traffic_server`Allocator::Allocator(this=0x000100c2fc18,
name=0x000100c1f0e0, element_size=1024, chunk_size=128, alignment=8) + 49
at Allocator.h:88
frame #5: 0x000100bf3367 libtsutil.3.dylib`__cxx_global_var_init + 39
at Arena.cc:33
frame #6: 0x000100bf3379 libtsutil.3.dylib`_GLOBAL__I_a + 9 at
Arena.cc:88
frame #7: 0x7fff5fc13378
dyld`ImageLoaderMachO::doModInitFunctions(ImageLoader::LinkContext const) +
236
{code}
--
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
