[jira] [Commented] (TS-5059) ATS 7.0.0 build fails with OpenSSL 1.1.0c
[
https://issues.apache.org/jira/browse/TS-5059?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15793562#comment-15793562
]
Jack Bates commented on TS-5059:
I think the problem is that SSL_set_rbio() was renamed SSL_set0_rbio()?
Apparently it was renamed before OpenSSL 1.1.0 was released [1][2].
[1]
https://github.com/openssl/openssl/commit/65e2d672548e7c4bcb28f1c5c835362830b1745b
[2] https://rt.openssl.org/Ticket/Display.html?id=4572
> ATS 7.0.0 build fails with OpenSSL 1.1.0c
> -
>
> Key: TS-5059
> URL: https://issues.apache.org/jira/browse/TS-5059
> Project: Traffic Server
> Issue Type: Bug
> Components: SSL, TLS
>Reporter: Jean Baptiste Favre
> Fix For: 7.1.0
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> ATS 7.0.0 build currently fails with following error:
> {code}SSLInternal.cc: In function ‘void SSL_set_rbio(SSL*, BIO*)’:
> SSLInternal.cc:40:10: error: invalid use of incomplete type ‘SSL {aka
> struct ssl_st}’
>if (ssl->rbio != NULL) {
> ^~
> In file included from /usr/include/openssl/crypto.h:31:0,
> from /usr/include/openssl/comp.h:16,
> from /usr/include/openssl/ssl.h:47,
> from SSLInternal.cc:33:
> /usr/include/openssl/ossl_typ.h:144:16: note: forward declaration of
> ‘SSL {aka struct ssl_st}’
> typedef struct ssl_st SSL;
> ^~
> SSLInternal.cc:41:17: error: invalid use of incomplete type ‘SSL {aka
> struct ssl_st}’
> BIO_free(ssl->rbio);
> ^~
> In file included from /usr/include/openssl/crypto.h:31:0,
> from /usr/include/openssl/comp.h:16,
> from /usr/include/openssl/ssl.h:47,
> from SSLInternal.cc:33:
> /usr/include/openssl/ossl_typ.h:144:16: note: forward declaration of
> ‘SSL {aka struct ssl_st}’
> typedef struct ssl_st SSL;
> ^~
> SSLInternal.cc:43:6: error: invalid use of incomplete type ‘SSL {aka
> struct ssl_st}’
>ssl->rbio = rbio;
> ^~
> In file included from /usr/include/openssl/crypto.h:31:0,
> from /usr/include/openssl/comp.h:16,
> from /usr/include/openssl/ssl.h:47,
> from SSLInternal.cc:33:
> /usr/include/openssl/ossl_typ.h:144:16: note: forward declaration of
> ‘SSL {aka struct ssl_st}’
> typedef struct ssl_st SSL;
> ^~
> {code}
> The full configure log can be found here:
> https://gist.github.com/jbfavre/00f63362b435d8ffc682d42d29b671f2
> According to https://wiki.openssl.org/index.php/1.1_API_Changes :
> > setting SSL->rbio without setting SSL->wbio. New function introduction
> in 1.1.0 to handle this: SSL_set_rbio()".
> Problem is, rbio doesn't seems to be nicely detected at configure stage:
> {code}checking for SSL_set_rbio... no
> checking whether to enable set rbio... no{code}
> Binding ATS to OpenSSL 1.0 still works.
> Regards,
> Jean Baptiste Favre
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Resolved] (TS-2832) Add links from an API description to the code for that object
[ https://issues.apache.org/jira/browse/TS-2832?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Bates resolved TS-2832. Resolution: Fixed Add links from an API description to the code for that object - Key: TS-2832 URL: https://issues.apache.org/jira/browse/TS-2832 Project: Traffic Server Issue Type: Bug Reporter: Jack Bates Fix For: Docs Doxygen knows where in the code objects are located. This uses that info to add links from the documentation into the code. Based on the sphinx.ext.viewcode and sphinx.ext.linkcode extensions. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-3037) Support Setting Of Priority Code Point (PCP) Per IEEE_802.1Q
[ https://issues.apache.org/jira/browse/TS-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14114571#comment-14114571 ] Jack Bates commented on TS-3037: I added some notes on the PCP Field to the wiki: https://cwiki.apache.org/confluence/display/TS/Traffic+Shaping#TrafficShaping-PCPField There's an example of a plugin that can set the PCP Field based on the request target. Support Setting Of Priority Code Point (PCP) Per IEEE_802.1Q Key: TS-3037 URL: https://issues.apache.org/jira/browse/TS-3037 Project: Traffic Server Issue Type: New Feature Reporter: Jason Strongman Fix For: sometime Modify ATS to allow setting another socket option, SO_PRIORITY. This parameter should be set on new connections created by ATS. The parameter should also be set on responses back to clients. This parameter should also be set based on request or response conditions. So preferably allowing the parameter to be defined within the header_rewrite or lua plugins. This parameter should only impact layer 2 and should have no impacts on the layer 3 DSCP values. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2597) QoS (Quality of Service) Support ZPH (Zero Penalty HIT)
[ https://issues.apache.org/jira/browse/TS-2597?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14114572#comment-14114572 ] Jack Bates commented on TS-2597: I added some notes on this and traffic shaping in general to the wiki: https://cwiki.apache.org/confluence/display/TS/Traffic+Shaping#TrafficShaping-ZeroPenaltyHit I'm skeptical that it isn't better to directly manage the bandwidth between the proxy and origin? I think the use case for this Squid feature is the management of upstream bandwidth without limiting access to content that's already cached. You can mark traffic sent *from* the origin with the CONNMARK iptables/ip6tables target. That and transparency can help directly manage the bandwidth between the proxy and origin. QoS (Quality of Service) Support ZPH (Zero Penalty HIT) --- Key: TS-2597 URL: https://issues.apache.org/jira/browse/TS-2597 Project: Traffic Server Issue Type: New Feature Components: Plugins Reporter: Faysal Banna Fix For: sometime Hello there. I know it would be easy for someone in development team to create a module (plugin) that enables to set QoS markers on outgoing traffic. as such : Allows admin to set a TOS/Diffserv value to mark local hits. thus allowing missed (non locally cached )objects to have certain TOS/Diffserv and HITs (locally cached) objects to have different TOS/Diffserv. Much Regards Faysal Banna -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2967) failed assert if ssl_multicert.config doesn't exist
[
https://issues.apache.org/jira/browse/TS-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091882#comment-14091882
]
Jack Bates commented on TS-2967:
bq. The only place I can see that needs a NULL check is
{{SSLNetVConnection::sslStartHandShake()}}
Hmm what should {{SSLNetVConnection::sslStartHandShake()}} do if
{{SSLCertificateConfig::scoped_config}} is NULL?
I think it makes sense for it to behave the same if {{ssl_multicert.config}}
doesn't exist as if it is blank so if {{SSLCertificateConfig::scoped_config}}
is NULL because {{ssl_multicert.config}} doesn't exist then I think
{{SSLNetVConnection::sslStartHandShake()}} needs the
{{lookup-defaultContext()}} that results from the following lines in
{{SSLParseCertificateConfiguration()}}
{code}
// We *must* have a default context even if it can't possibly work. The
default context is used to
// bootstrap the SSL handshake so that we can subsequently do the SNI lookup
to switch to the real
// context.
if (lookup-ssl_default == NULL) {
ssl_user_config sslMultiCertSettings;
sslMultiCertSettings.addr = ats_strdup(*);
ssl_store_ssl_context(params, lookup, sslMultiCertSettings);
}
{code}
What about the following change?
{code}
--- a/iocore/net/SSLUtils.cc
+++ b/iocore/net/SSLUtils.cc
@@ -1476,10 +1476,7 @@ SSLParseCertificateConfiguration(
file_buf = readIntoBuffer(params-configFilePath, __func__, NULL);
}
- if (!file_buf) {
-Error(failed to read SSL certificate configuration from %s, params-confi
-return false;
- }
+ if (file_buf) {
// elevate/allow file access to root read only files/certs
uint32_t elevate_setting = 0;
@@ -1521,6 +1518,9 @@ SSLParseCertificateConfiguration(
line = tokLine(NULL, tok_state);
}
+ } else {
+Error(failed to read SSL certificate configuration from %s, params-confi
+ }
// We *must* have a default context even if it can't possibly work. The defau
// bootstrap the SSL handshake so that we can subsequently do the SNI lookup
{code}
This change resolves this issue because {{SSLCertificateConfig::reconfigure()}}
will now initialize {{configid}} when {{ssl_multicert.config}} doesn't exist
and it makes {{SSLNetVConnection::sslStartHandShake()}} behave the same if
{{ssl_multicert.config}} doesn't exist as if it is blank.
failed assert if ssl_multicert.config doesn't exist
---
Key: TS-2967
URL: https://issues.apache.org/jira/browse/TS-2967
Project: Traffic Server
Issue Type: Bug
Reporter: Jack Bates
Assignee: Jack Bates
Fix For: 5.1.0
If an ssl_multicert.config file doesn't exist then
SSLParseCertificateConfiguration() returns false (SSLUtils.cc line 1435)
and SSLCertificateConfig::reconfigure() doesn't initialize configid
(SSLConfig.cc line 333)
Then when SSLRecRawStatSyncCount() calls SSLCertificateConfig::acquire()
(SSLUtils.cc line 502)
it calls ConfigProcessor::get() with configid zero (SSLConfig.cc line 342)
and there's an ink_assert(id != 0) (ProxyConfig.cc line 175)
One way to avoid the failed assert is if SSLCertificateConfig::acquire() and
SSLCertificateConfig::release() only call ConfigProcessor::get/release() if
(configid !=0)
Another way might be if SSLCertificateConfig::reconfigure() initialized
configid with configProcessor.set(configid, NULL) if
SSLParseCertificateConfiguration() returns false?
Or SSLParseCertificateConfiguration() could treat a nonexistent
ssl_multicert.config the same as it treats a blank file? ({{touch
ssl_multicert.config}} makes the failed assert go away.)
Or maybe there's another better way to avoid the failed assert?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (TS-2995) Setting client response TOS/DSCP field has no effect
[
https://issues.apache.org/jira/browse/TS-2995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Bates updated TS-2995:
---
Summary: Setting client response TOS/DSCP field has no effect (was:
Setting client connection TOS/DSCP field has no effect)
Setting client response TOS/DSCP field has no effect
Key: TS-2995
URL: https://issues.apache.org/jira/browse/TS-2995
Project: Traffic Server
Issue Type: Bug
Reporter: Jack Bates
Assignee: Jack Bates
Fix For: 5.1.0
{{proxy.config.net.sock_packet_tos_in}} has no effect if
{{proxy.config.accept_threads}} is not zero.
If it is zero then {{UnixNetProcessor::accept_internal()}} calls
{{NetAccept::init_accept_per_thread()}} which eventually calls
{{NetAccept::acceptFastEvent()}} in which there's code to set the {{SO_MARK}}
and {{IP_TOS}} socket options.
But if it's not zero then {{UnixNetProcessor::accept_internal()}} instead
calls {{NetAccept::init_accept_loop()}} which eventually calls
{{NetAccept::do_blocking_accept()}}
One fix is to copy the code to set the {{SO_MARK}} and {{IP_TOS}} socket
options from {{NetAccept::acceptFastEvent()}} to
{{NetAccept::do_blocking_accept()}}
{code}
--- a/iocore/net/UnixNetAccept.cc
+++ b/iocore/net/UnixNetAccept.cc
@@ -275,6 +275,18 @@ NetAccept::do_blocking_accept(EThread * t)
return -1;
}
+#if TS_HAS_SO_MARK
+ if (packet_mark != 0) {
+safe_setsockopt(con.fd, SOL_SOCKET, SO_MARK, reinterpret_castchar
*(
+ }
+#endif
+
+#if TS_HAS_IP_TOS
+ if (packet_tos != 0) {
+safe_setsockopt(con.fd, IPPROTO_IP, IP_TOS, reinterpret_castchar
*(p
+ }
+#endif
+
// Use 'NULL' to Bypass thread allocator
vc = (UnixNetVConnection *)this-getNetProcessor()-allocate_vc(NULL);
if (!vc) {
{code}
I tested this change and verified that
{{proxy.config.net.sock_packet_tos_in}} does correctly set the TOS/DSCP field.
This issue was reported by Jason Strongman on the users list
http://thread.gmane.org/gmane.comp.apache.trafficserver.user/4141/focus=4202
{{proxy.config.net.sock_packet_tos_in}} was introduced in TS-1090 and commit
b77838991531d6cb402618c3d690b83e95b92d63
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2995) Setting client connection TOS/DSCP field has no effect
Jack Bates created TS-2995:
--
Summary: Setting client connection TOS/DSCP field has no effect
Key: TS-2995
URL: https://issues.apache.org/jira/browse/TS-2995
Project: Traffic Server
Issue Type: Bug
Reporter: Jack Bates
{{proxy.config.net.sock_packet_tos_in}} has no effect if
{{proxy.config.accept_threads}} is not zero.
If it is zero then {{UnixNetProcessor::accept_internal()}} calls
{{NetAccept::init_accept_per_thread()}} which eventually calls
{{NetAccept::acceptFastEvent()}} in which there's code to set the {{SO_MARK}}
and {{IP_TOS}} socket options.
But if it's not zero then {{UnixNetProcessor::accept_internal()}} instead calls
{{NetAccept::init_accept_loop()}} which eventually calls
{{NetAccept::do_blocking_accept()}}
One fix is to copy the code to set the {{SO_MARK}} and {{IP_TOS}} socket
options from {{NetAccept::acceptFastEvent()}} to
{{NetAccept::do_blocking_accept()}}
{code}
--- a/iocore/net/UnixNetAccept.cc
+++ b/iocore/net/UnixNetAccept.cc
@@ -275,6 +275,18 @@ NetAccept::do_blocking_accept(EThread * t)
return -1;
}
+#if TS_HAS_SO_MARK
+ if (packet_mark != 0) {
+safe_setsockopt(con.fd, SOL_SOCKET, SO_MARK, reinterpret_castchar *(
+ }
+#endif
+
+#if TS_HAS_IP_TOS
+ if (packet_tos != 0) {
+safe_setsockopt(con.fd, IPPROTO_IP, IP_TOS, reinterpret_castchar *(p
+ }
+#endif
+
// Use 'NULL' to Bypass thread allocator
vc = (UnixNetVConnection *)this-getNetProcessor()-allocate_vc(NULL);
if (!vc) {
{code}
I tested this change and verified that {{proxy.config.net.sock_packet_tos_in}}
does correctly set the TOS/DSCP field.
This issue was reported by Jason Strongman on the users list
http://thread.gmane.org/gmane.comp.apache.trafficserver.user/4141/focus=4202
{{proxy.config.net.sock_packet_tos_in}} was introduced in TS-1090 and commit
b77838991531d6cb402618c3d690b83e95b92d63
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2967) failed assert if ssl_multicert.config doesn't exist
[
https://issues.apache.org/jira/browse/TS-2967?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14079566#comment-14079566
]
Jack Bates commented on TS-2967:
I'm happy to axe those asserts
(you know this stuff far better than I do)
but I worry you might want them if you accidentally call
{{ConfigProcessor::get()}} with an invalid index? (Say from another place where
{{ConfigProcessor::get()}} is used.)
What about checking if {{configid}} is initialized in
{{SSLCertificateConfig::acquire()}} and {{SSLCertificateConfig::release()}}?
{code}
--- a/iocore/net/SSLConfig.cc
+++ b/iocore/net/SSLConfig.cc
@@ -339,12 +339,16 @@ SSLCertificateConfig::reconfigure()
SSLCertLookup *
SSLCertificateConfig::acquire()
{
- return (SSLCertLookup *)configProcessor.get(configid);
+ if (configid != 0) {
+return (SSLCertLookup *)configProcessor.get(configid);
+ }
}
void
SSLCertificateConfig::release(SSLCertLookup * lookup)
{
- configProcessor.release(configid, lookup);
+ if (configid != 0) {
+configProcessor.release(configid, lookup);
+ }
}
{code}
failed assert if ssl_multicert.config doesn't exist
---
Key: TS-2967
URL: https://issues.apache.org/jira/browse/TS-2967
Project: Traffic Server
Issue Type: Bug
Reporter: Jack Bates
If an ssl_multicert.config file doesn't exist then
SSLParseCertificateConfiguration() returns false (SSLUtils.cc line 1435)
and SSLCertificateConfig::reconfigure() doesn't initialize configid
(SSLConfig.cc line 333)
Then when SSLRecRawStatSyncCount() calls SSLCertificateConfig::acquire()
(SSLUtils.cc line 502)
it calls ConfigProcessor::get() with configid zero (SSLConfig.cc line 342)
and there's an ink_assert(id != 0) (ProxyConfig.cc line 175)
One way to avoid the failed assert is if SSLCertificateConfig::acquire() and
SSLCertificateConfig::release() only call ConfigProcessor::get/release() if
(configid !=0)
Another way might be if SSLCertificateConfig::reconfigure() initialized
configid with configProcessor.set(configid, NULL) if
SSLParseCertificateConfiguration() returns false?
Or SSLParseCertificateConfiguration() could treat a nonexistent
ssl_multicert.config the same as it treats a blank file? ({{touch
ssl_multicert.config}} makes the failed assert go away.)
Or maybe there's another better way to avoid the failed assert?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (TS-2967) failed assert if ssl_multicert.config doesn't exist
Jack Bates created TS-2967:
--
Summary: failed assert if ssl_multicert.config doesn't exist
Key: TS-2967
URL: https://issues.apache.org/jira/browse/TS-2967
Project: Traffic Server
Issue Type: Bug
Reporter: Jack Bates
If an ssl_multicert.config file doesn't exist then
SSLParseCertificateConfiguration() returns false (SSLUtils.cc line 1435)
and SSLCertificateConfig::reconfigure() doesn't initialize configid
(SSLConfig.cc line 333)
Then when SSLRecRawStatSyncCount() calls SSLCertificateConfig::acquire()
(SSLUtils.cc line 502)
it calls ConfigProcessor::get() with configid zero (SSLConfig.cc line 342)
and there's an ink_assert(id != 0) (ProxyConfig.cc line 175)
One way to avoid the failed assert is if SSLCertificateConfig::acquire() and
SSLCertificateConfig::release() only call ConfigProcessor::get/release() if
(configid !=0)
Another way might be if SSLCertificateConfig::reconfigure() initialized
configid with configProcessor.set(configid, NULL) if
SSLParseCertificateConfiguration() returns false?
Or SSLParseCertificateConfiguration() could treat a nonexistent
ssl_multicert.config the same as it treats a blank file? ({{touch
ssl_multicert.config}} makes the failed assert go away.)
Or maybe there's another better way to avoid the failed assert?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2553) Fix a segfault in the Metalink plugin reported by Faysal Banna and preserve the Content-Length header
[
https://issues.apache.org/jira/browse/TS-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14076929#comment-14076929
]
Jack Bates commented on TS-2553:
Thanks for helping me find these problems!
I committed a fix for an unrelated crash but I haven't been able to reproduce
the crash that you reported yet.
Can you find the core dump that gets created when the proxy crashes?
If so can you send me a back trace?
The core dump is a file called core in the Traffic Server root directory
(e.g. /usr/local/core)
To get a back trace run the following command:
bq. $ gdb /usr/local/core /usr/local/bin/traffic_server
At the GDB prompt issue the {{bt}} command and send me the output.
Fix a segfault in the Metalink plugin reported by Faysal Banna and preserve
the Content-Length header
-
Key: TS-2553
URL: https://issues.apache.org/jira/browse/TS-2553
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Jack Bates
Assignee: James Peach
Fix For: 5.0.0
Fix a segfault in the Metalink plugin reported by Faysal Banna:
https://github.com/jablko/dedup/issues/1
Copy the upstream nbytes (if known) downstream to preserve the Content-Length
header.
Improve comments in the plugin code.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Comment Edited] (TS-2553) Fix a segfault in the Metalink plugin reported by Faysal Banna and preserve the Content-Length header
[
https://issues.apache.org/jira/browse/TS-2553?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14076929#comment-14076929
]
Jack Bates edited comment on TS-2553 at 7/28/14 9:49 PM:
-
Thanks for helping me find these problems!
I committed a fix for an unrelated crash but I haven't been able to reproduce
the crash that you reported yet.
Can you find the core dump that gets created when the proxy crashes?
If so can you send me a back trace?
The core dump is a file called core in the Traffic Server root directory
(e.g. /usr/local/core)
To get a back trace run the following command:
bq. $ gdb /usr/local/core /usr/local/bin/traffic_server
At the GDB prompt issue the {{bt}} command and send me the output.
If you have any questions or problems please let me know.
With the extra details above I will work on fixing the problem.
was (Author: nottheoilrig):
Thanks for helping me find these problems!
I committed a fix for an unrelated crash but I haven't been able to reproduce
the crash that you reported yet.
Can you find the core dump that gets created when the proxy crashes?
If so can you send me a back trace?
The core dump is a file called core in the Traffic Server root directory
(e.g. /usr/local/core)
To get a back trace run the following command:
bq. $ gdb /usr/local/core /usr/local/bin/traffic_server
At the GDB prompt issue the {{bt}} command and send me the output.
Fix a segfault in the Metalink plugin reported by Faysal Banna and preserve
the Content-Length header
-
Key: TS-2553
URL: https://issues.apache.org/jira/browse/TS-2553
Project: Traffic Server
Issue Type: Bug
Components: Plugins
Reporter: Jack Bates
Assignee: James Peach
Fix For: 5.0.0
Fix a segfault in the Metalink plugin reported by Faysal Banna:
https://github.com/jablko/dedup/issues/1
Copy the upstream nbytes (if known) downstream to preserve the Content-Length
header.
Improve comments in the plugin code.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (TS-2939) Metalink: Fix crash when checking the digest of a file that wasn't cacheable
[ https://issues.apache.org/jira/browse/TS-2939?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Bates resolved TS-2939. Resolution: Fixed Metalink: Fix crash when checking the digest of a file that wasn't cacheable Key: TS-2939 URL: https://issues.apache.org/jira/browse/TS-2939 Project: Traffic Server Issue Type: Bug Reporter: Jack Bates Assignee: Jack Bates Fix For: sometime TSCacheRead() is reentrant particularly in case of a cache miss so its handler might execute sooner than expected particularly when the Metalink plugin is checking the digest of a file that wasn't cacheable. This TSCacheRead() handler will clean up an earlier TSVConnRead() buffer but CacheVC::openReadMain() will continue operating on the buffer and crash. Close the virtual connection to stop it from operating on the buffer. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2939) Metalink: Fix crash when checking the digest of a file that wasn't cacheable
Jack Bates created TS-2939: -- Summary: Metalink: Fix crash when checking the digest of a file that wasn't cacheable Key: TS-2939 URL: https://issues.apache.org/jira/browse/TS-2939 Project: Traffic Server Issue Type: Bug Reporter: Jack Bates TSCacheRead() is reentrant particularly in case of a cache miss so its handler might execute sooner than expected particularly when the Metalink plugin is checking the digest of a file that wasn't cacheable. This TSCacheRead() handler will clean up an earlier TSVConnRead() buffer but CacheVC::openReadMain() will continue operating on the buffer and crash. Close the virtual connection to stop it from operating on the buffer. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2832) Add links from an API description to the code for that object
Jack Bates created TS-2832: -- Summary: Add links from an API description to the code for that object Key: TS-2832 URL: https://issues.apache.org/jira/browse/TS-2832 Project: Traffic Server Issue Type: Bug Reporter: Jack Bates Doxygen knows where in the code objects are located. This uses that info to add links from the documentation into the code. Based on the sphinx.ext.viewcode and sphinx.ext.linkcode extensions. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2803) Use documentation strings extracted from source files in project documentation
[ https://issues.apache.org/jira/browse/TS-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13998833#comment-13998833 ] Jack Bates commented on TS-2803: Thanks! Use documentation strings extracted from source files in project documentation -- Key: TS-2803 URL: https://issues.apache.org/jira/browse/TS-2803 Project: Traffic Server Issue Type: Bug Components: Documentation Reporter: Jack Bates Assignee: James Peach Fix For: 5.0.0 Add a Sphinx extension that can grab documentation strings that have been extracted from source files by Doxygen, translate them into reStructuredText, and then use them inside Sphinx documents. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (TS-2803) Use documentation strings extracted from source files in project documentation
[ https://issues.apache.org/jira/browse/TS-2803?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jack Bates updated TS-2803: --- Description: Add a Sphinx extension that can grab documentation strings that have been extracted from source files by Doxygen, translate them into reStructuredText, and then use them inside Sphinx documents. (was: Add a Sphinx extension that can grab documentation strings that have been extracted from source files by Doxygen, translate them into reStructurredText, and then use them inside Sphinx documents.) Use documentation strings extracted from source files in project documentation -- Key: TS-2803 URL: https://issues.apache.org/jira/browse/TS-2803 Project: Traffic Server Issue Type: Bug Reporter: Jack Bates Add a Sphinx extension that can grab documentation strings that have been extracted from source files by Doxygen, translate them into reStructuredText, and then use them inside Sphinx documents. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2803) Use documentation strings extracted from source files in project documentation
Jack Bates created TS-2803: -- Summary: Use documentation strings extracted from source files in project documentation Key: TS-2803 URL: https://issues.apache.org/jira/browse/TS-2803 Project: Traffic Server Issue Type: Bug Reporter: Jack Bates Add a Sphinx extension that can grab documentation strings that have been extracted from source files by Doxygen, translate them into reStructurredText, and then use them inside Sphinx documents. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2797) Not all manpages getting built
Jack Bates created TS-2797: -- Summary: Not all manpages getting built Key: TS-2797 URL: https://issues.apache.org/jira/browse/TS-2797 Project: Traffic Server Issue Type: Bug Reporter: Jack Bates Not all of the manpages are getting built because they are not part of the man_pages list in doc/conf.py This patch adds all of the files in the doc/reference/api directory to the list of manual pages. It also adds the manual page descriptions to the HTML output. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2675) metalink: Fix crash and plug memory leaks
Jack Bates created TS-2675: -- Summary: metalink: Fix crash and plug memory leaks Key: TS-2675 URL: https://issues.apache.org/jira/browse/TS-2675 Project: Traffic Server Issue Type: Bug Reporter: Jack Bates Fix crash if INKVConnInternal::do_io_close() gets called after a message is already complete, plug memory leaks reported by Valgrind, and don't finish computing the digest more than once. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (TS-2589) Headers delayed until the origin server starts sending content
Jack Bates created TS-2589: -- Summary: Headers delayed until the origin server starts sending content Key: TS-2589 URL: https://issues.apache.org/jira/browse/TS-2589 Project: Traffic Server Issue Type: Bug Reporter: Jack Bates If there is a transform (for example a null transform) then the response headers aren't forwarded until the origin server starts sending content. Normally (without a transform) the headers are forwarded as soon as they are done, whether content is available yet or not. The headers are sent when the transform calls TSVConnWrite() and the transform is called at the end of the headers/start of the content. But it's not called if the available content is empty. A possible fix is to call the transform at the start of the content whether content is available yet or not. This doesn't affect a buffered transform which can still delay and update the headers until it calls TSVConnWrite() -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (TS-2584) failed assert transforming and caching negative response
Jack Bates created TS-2584:
--
Summary: failed assert transforming and caching negative response
Key: TS-2584
URL: https://issues.apache.org/jira/browse/TS-2584
Project: Traffic Server
Issue Type: Bug
Reporter: Jack Bates
If negative caching is enabled and you transform a negative response (for
example a null transform) there is a failed assert in
HttpTransact::set_headers_for_cache_write()
{noformat}
FATAL: HttpTransact.cc:4811: failed assert `cache_info-response_get()-valid()`
proxy/.libs/lt-traffic_server - STACK TRACE:
lib/ts/.libs/libtsutil.so.5(ink_fatal_die+0x0)[0xb77a6445]
lib/ts/.libs/libtsutil.so.5(+0x22269)[0xb77a5269]
proxy/.libs/lt-traffic_server(_ZN12HttpTransact27set_headers_for_cache_writeEPNS_5StateEP8HTTPInfoP7HTTPHdrS5_+0x1da)[0x81c0ae6]
proxy/.libs/lt-traffic_server(_ZN12HttpTransact22handle_transform_readyEPNS_5StateE+0x272)[0x81c0576]
proxy/.libs/lt-traffic_server(_ZN6HttpSM32call_transact_and_set_next_stateEPFvPN12HttpTransact5StateEE+0x78)[0x81a4b3e]
proxy/.libs/lt-traffic_server(_ZN6HttpSM38state_response_wait_for_transform_readEiPv+0x196)[0x81926b0]
proxy/.libs/lt-traffic_server(_ZN6HttpSM12main_handlerEiPv+0x2df)[0x81969b5]
proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x47)[0x811b427]
proxy/.libs/lt-traffic_server(_ZN17TransformTerminus12handle_eventEiPv+0x27f)[0x815d81b]
proxy/.libs/lt-traffic_server(_ZN12Continuation11handleEventEiPv+0x47)[0x811b427]
proxy/.libs/lt-traffic_server(_ZN7EThread13process_eventEP5Eventi+0x104)[0x8300692]
proxy/.libs/lt-traffic_server(_ZN7EThread7executeEv+0xd6)[0x8300916]
proxy/.libs/lt-traffic_server[0x82ff569]
/lib/i686/cmov/libpthread.so.0(+0x5955)[0xb7467955]
/lib/i686/cmov/libc.so.6(clone+0x5e)[0xb717f1de]
Aborted (core dumped)
{noformat}
HttpTransact::handle_transform_ready() passes s-cache_info.transform_store to
HttpTransact::set_headers_for_cache_write()
The -valid() test at the top of HttpTransact::set_headers_for_cache_write()
fails so -create() gets called.
{code}
if (!cache_info-valid()) {
cache_info-create();
}
{code}
(s-cache_info.transform_store-m_alt is NULL. I didn't look into why this is,
is it expected?)
Because s-negative_caching is true, cache_info-response_set(response) doesn't
get called, instead the assert fails.
{code}
if (!s-negative_caching)
cache_info-response_set(response);
else {
ink_assert(cache_info-response_get()-valid());
}
{code}
Assuming the cache_info-valid() test can fail and s-negative_caching can be
true at the same time, one possible solution is to fix the logic so
cache_info-response_set(response) gets called?
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
[jira] [Created] (TS-2578) TSVConnAbort(output_vc) doesn't close the client connection
Jack Bates created TS-2578: -- Summary: TSVConnAbort(output_vc) doesn't close the client connection Key: TS-2578 URL: https://issues.apache.org/jira/browse/TS-2578 Project: Traffic Server Issue Type: Bug Reporter: Jack Bates If a transform has sent any content downstream before it decides to call TSVConnAbort(output_vc) or TSVConnClose(output_vc) then the client connection doesn't get closed. If TransformTerminus::handle_event() sends VC_EVENT_ERROR or VC_EVENT_EOS events then the client connection does get closed, but it only sends these if m_called_user is false. After any content has been sent downstream, m_called_user is true. One possible solution is to fix the logic in TransformTerminus::handle_event() so it sends these events. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (TS-2553) Fix a segfault in the Metalink plugin reported by Faysal Banna and preserve the Content-Length header
Jack Bates created TS-2553: -- Summary: Fix a segfault in the Metalink plugin reported by Faysal Banna and preserve the Content-Length header Key: TS-2553 URL: https://issues.apache.org/jira/browse/TS-2553 Project: Traffic Server Issue Type: Bug Reporter: Jack Bates Fix a segfault in the Metalink plugin reported by Faysal Banna: https://github.com/jablko/dedup/issues/1 Copy the upstream nbytes (if known) downstream to preserve the Content-Length header. Improve comments in the plugin code. -- This message was sent by Atlassian JIRA (v6.1.5#6160)
[jira] [Created] (TS-1924) Add README to Metalink plugin
Jack Bates created TS-1924: -- Summary: Add README to Metalink plugin Key: TS-1924 URL: https://issues.apache.org/jira/browse/TS-1924 Project: Traffic Server Issue Type: Improvement Components: Plugins Reporter: Jack Bates Here is a README for the Metalink plugin: http://nottheoilrig.com/trafficserver/readme.patch Can I please contribute it to the plugins/experimental/metalink directory? -- 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-1528) ats_memalign: couldn't allocate -548249600 bytes in Vol::init()
[
https://issues.apache.org/jira/browse/TS-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13533310#comment-13533310
]
Jack Bates commented on TS-1528:
I re-tested with the latest master (544e64678eecb80a63b88b9efe573ecb42836c24),
here is the output with the cache_init tag:
http://nottheoilrig.com/trafficserver/201212160/stderr
I notice the new log message explaining that it will allocate over 3GB of
memory for directory entries for our 3TB disk (with min_average_object_size
8K), and I notice that the overflow in the ats_memalign failure log message is
gone. I think this issue is resolved, thank you for your support!
We've now been running Traffic Server (release 3.2.0) for a couple months with
the 3TB disk, min_average_object_size 64K, and
proxy.config.cache.ram_cache.size 32M. It works, but I notice that when a lot
of users are online, downloading even cached files is slow. I'm not sure what
specifically is the problem, maybe our CPU and RAM aren't sufficient. The disk
is external, connected with USB2. I think fast disk access is important to
Traffic Server, so maybe the USB bus is the weakest link?
Long term, we plan to upgrade to 64-bit hardware with at least 4GB of RAM and
OOE support, ideally an i3 or i5 processor. I'm looking at stuff from Zotac and
Shuttle. Meanwhile I plan to scrap the 3TB disk and install Traffic Server on
an SD card, then use the entire internal 160GB disk as a raw device. I guess
this will need about 160MB of RAM for directory entries with default settings,
and another 160MB for RAM cache, which is well withing our 1GB of RAM.
ats_memalign: couldn't allocate -548249600 bytes in Vol::init()
---
Key: TS-1528
URL: https://issues.apache.org/jira/browse/TS-1528
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.2.0
Environment: Debian testing (wheezy) on i686
Reporter: Jack Bates
Assignee: James Peach
Fix For: 3.3.3
I consistently get the following error whenever I try to start Traffic Server
(release 3.2.0). Yesterday I built Traffic Server from Git HEAD (34a2ba) to
check if it behaves any differently, but I consistently reproduce this same
error whenever I try to start it, too
Here's my configuration, which is pretty minimal:
http://nottheoilrig.com/trafficserver/201210120/
What details can I provide to help debug this? James Peach suggested
attaching some kind of dump of the volume header:
http://mail-archives.apache.org/mod_mbox/trafficserver-users/201210.mbox/%3C9ED91AE2-2F52-4BDB-9088-E14D40642C34%40apache.org%3E
{code}
administrator@debian$ TS_ROOT=/home/administrator/trafficserver
trafficserver/traffic_server
[TrafficServer] using root directory '/home/administrator/trafficserver'
FATAL: ats_memalign: couldn't allocate -548249600 bytes at alignment 4096 -
insufficient memory
trafficserver/traffic_server - STACK TRACE:
trafficserver/libtsutil.so.3(+0x1075b)[0xb76d075b]
trafficserver/libtsutil.so.3(ats_memalign+0xa1)[0xb76d34c1]
trafficserver/traffic_server(_ZN3Vol4initEPcxxb+0x282)[0x827bd52]
trafficserver/traffic_server(_ZN5Cache4openEbb+0x5d8)[0x827dc48]
trafficserver/traffic_server(_ZN14CacheProcessor15diskInitializedEv+0x323)[0x827e0d3]
trafficserver/traffic_server(_ZN9CacheDisk9openStartEiPv+0x483)[0x828c9c3]
trafficserver/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x25)[0x8280a75]
trafficserver/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8b)[0x830343b]
trafficserver/traffic_server(_ZN7EThread7executeEv+0x723)[0x8304003]
trafficserver/traffic_server(main+0x178d)[0x80c572d]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb7039e46]
trafficserver/traffic_server[0x80cabdd]
administrator@debian:~$
{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-1528) ats_memalign: couldn't allocate -548249600 bytes in Vol::init()
[
https://issues.apache.org/jira/browse/TS-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13490154#comment-13490154
]
Jack Bates commented on TS-1528:
Thank you very much for your support James Peach, and for the support I
received in IRC. Traffic Server is running on a dedicated EeeBox B202 machine,
with an Intel Atom N270 processor (32-bit) and 1 GB of RAM
Thanks a lot for these improved log messages. I haven't yet had a chance to
re-test master, but expect they will make it much easier to understand problems
like this in future. I will re-test and post the output
With help on IRC, I was able to avoid this integer overflow by increasing
proxy.config.cache.min_average_object_size to 16K, but when I started Traffic
Server, the system load average would climb because Traffic Server used all
available memory, and eventually segfaulted. I set
proxy.config.cache.ram_cache.size to zero and increased
proxy.config.cache.min_average_object_size until it used less than all
available memory. It's been running okay for about a week now, with
proxy.config.cache.ram_cache.size zero and
proxy.config.cache.min_average_object_size 64K
I'm now experimenting with re-enabling a 256M RAM cache
ats_memalign: couldn't allocate -548249600 bytes in Vol::init()
---
Key: TS-1528
URL: https://issues.apache.org/jira/browse/TS-1528
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.2.0
Environment: Debian testing (wheezy) on i686
Reporter: Jack Bates
Assignee: James Peach
I consistently get the following error whenever I try to start Traffic Server
(release 3.2.0). Yesterday I built Traffic Server from Git HEAD (34a2ba) to
check if it behaves any differently, but I consistently reproduce this same
error whenever I try to start it, too
Here's my configuration, which is pretty minimal:
http://nottheoilrig.com/trafficserver/201210120/
What details can I provide to help debug this? James Peach suggested
attaching some kind of dump of the volume header:
http://mail-archives.apache.org/mod_mbox/trafficserver-users/201210.mbox/%3C9ED91AE2-2F52-4BDB-9088-E14D40642C34%40apache.org%3E
{code}
administrator@debian$ TS_ROOT=/home/administrator/trafficserver
trafficserver/traffic_server
[TrafficServer] using root directory '/home/administrator/trafficserver'
FATAL: ats_memalign: couldn't allocate -548249600 bytes at alignment 4096 -
insufficient memory
trafficserver/traffic_server - STACK TRACE:
trafficserver/libtsutil.so.3(+0x1075b)[0xb76d075b]
trafficserver/libtsutil.so.3(ats_memalign+0xa1)[0xb76d34c1]
trafficserver/traffic_server(_ZN3Vol4initEPcxxb+0x282)[0x827bd52]
trafficserver/traffic_server(_ZN5Cache4openEbb+0x5d8)[0x827dc48]
trafficserver/traffic_server(_ZN14CacheProcessor15diskInitializedEv+0x323)[0x827e0d3]
trafficserver/traffic_server(_ZN9CacheDisk9openStartEiPv+0x483)[0x828c9c3]
trafficserver/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x25)[0x8280a75]
trafficserver/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8b)[0x830343b]
trafficserver/traffic_server(_ZN7EThread7executeEv+0x723)[0x8304003]
trafficserver/traffic_server(main+0x178d)[0x80c572d]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb7039e46]
trafficserver/traffic_server[0x80cabdd]
administrator@debian:~$
{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] [Created] (TS-1528) ats_memalign: couldn't allocate -548249600 bytes in Vol::init()
Jack Bates created TS-1528:
--
Summary: ats_memalign: couldn't allocate -548249600 bytes in
Vol::init()
Key: TS-1528
URL: https://issues.apache.org/jira/browse/TS-1528
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.2.0
Environment: Debian testing (wheezy) on i686
Reporter: Jack Bates
I consistently get the following error whenever I try to start Traffic Server
(release 3.2.0). Yesterday I built Traffic Server from Git HEAD (34a2ba) to
check if it behaves any differently, but I consistently reproduce this same
error whenever I try to start it too
Here's my configuration, which is pretty minimal:
http://nottheoilrig.com/trafficserver/201210120/
What can I provide to help debug this? James Peach suggested attaching some
kind of dump of the volume header:
http://mail-archives.apache.org/mod_mbox/trafficserver-users/201210.mbox/%3C9ED91AE2-2F52-4BDB-9088-E14D40642C34%40apache.org%3E
{code}
administrator@debian$ TS_ROOT=/home/administrator/trafficserver
trafficserver/traffic_server
[TrafficServer] using root directory '/home/administrator/trafficserver'
FATAL: ats_memalign: couldn't allocate -548249600 bytes at alignment 4096 -
insufficient memory
trafficserver/traffic_server - STACK TRACE:
trafficserver/libtsutil.so.3(+0x1075b)[0xb76d075b]
trafficserver/libtsutil.so.3(ats_memalign+0xa1)[0xb76d34c1]
trafficserver/traffic_server(_ZN3Vol4initEPcxxb+0x282)[0x827bd52]
trafficserver/traffic_server(_ZN5Cache4openEbb+0x5d8)[0x827dc48]
trafficserver/traffic_server(_ZN14CacheProcessor15diskInitializedEv+0x323)[0x827e0d3]
trafficserver/traffic_server(_ZN9CacheDisk9openStartEiPv+0x483)[0x828c9c3]
trafficserver/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x25)[0x8280a75]
trafficserver/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8b)[0x830343b]
trafficserver/traffic_server(_ZN7EThread7executeEv+0x723)[0x8304003]
trafficserver/traffic_server(main+0x178d)[0x80c572d]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb7039e46]
trafficserver/traffic_server[0x80cabdd]
administrator@debian:~$
{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-1528) ats_memalign: couldn't allocate -548249600 bytes in Vol::init()
[
https://issues.apache.org/jira/browse/TS-1528?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jack Bates updated TS-1528:
---
Description:
I consistently get the following error whenever I try to start Traffic Server
(release 3.2.0). Yesterday I built Traffic Server from Git HEAD (34a2ba) to
check if it behaves any differently, but I consistently reproduce this same
error whenever I try to start it, too
Here's my configuration, which is pretty minimal:
http://nottheoilrig.com/trafficserver/201210120/
What details can I provide to help debug this? James Peach suggested attaching
some kind of dump of the volume header:
http://mail-archives.apache.org/mod_mbox/trafficserver-users/201210.mbox/%3C9ED91AE2-2F52-4BDB-9088-E14D40642C34%40apache.org%3E
{code}
administrator@debian$ TS_ROOT=/home/administrator/trafficserver
trafficserver/traffic_server
[TrafficServer] using root directory '/home/administrator/trafficserver'
FATAL: ats_memalign: couldn't allocate -548249600 bytes at alignment 4096 -
insufficient memory
trafficserver/traffic_server - STACK TRACE:
trafficserver/libtsutil.so.3(+0x1075b)[0xb76d075b]
trafficserver/libtsutil.so.3(ats_memalign+0xa1)[0xb76d34c1]
trafficserver/traffic_server(_ZN3Vol4initEPcxxb+0x282)[0x827bd52]
trafficserver/traffic_server(_ZN5Cache4openEbb+0x5d8)[0x827dc48]
trafficserver/traffic_server(_ZN14CacheProcessor15diskInitializedEv+0x323)[0x827e0d3]
trafficserver/traffic_server(_ZN9CacheDisk9openStartEiPv+0x483)[0x828c9c3]
trafficserver/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x25)[0x8280a75]
trafficserver/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8b)[0x830343b]
trafficserver/traffic_server(_ZN7EThread7executeEv+0x723)[0x8304003]
trafficserver/traffic_server(main+0x178d)[0x80c572d]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb7039e46]
trafficserver/traffic_server[0x80cabdd]
administrator@debian:~$
{code}
was:
I consistently get the following error whenever I try to start Traffic Server
(release 3.2.0). Yesterday I built Traffic Server from Git HEAD (34a2ba) to
check if it behaves any differently, but I consistently reproduce this same
error whenever I try to start it too
Here's my configuration, which is pretty minimal:
http://nottheoilrig.com/trafficserver/201210120/
What can I provide to help debug this? James Peach suggested attaching some
kind of dump of the volume header:
http://mail-archives.apache.org/mod_mbox/trafficserver-users/201210.mbox/%3C9ED91AE2-2F52-4BDB-9088-E14D40642C34%40apache.org%3E
{code}
administrator@debian$ TS_ROOT=/home/administrator/trafficserver
trafficserver/traffic_server
[TrafficServer] using root directory '/home/administrator/trafficserver'
FATAL: ats_memalign: couldn't allocate -548249600 bytes at alignment 4096 -
insufficient memory
trafficserver/traffic_server - STACK TRACE:
trafficserver/libtsutil.so.3(+0x1075b)[0xb76d075b]
trafficserver/libtsutil.so.3(ats_memalign+0xa1)[0xb76d34c1]
trafficserver/traffic_server(_ZN3Vol4initEPcxxb+0x282)[0x827bd52]
trafficserver/traffic_server(_ZN5Cache4openEbb+0x5d8)[0x827dc48]
trafficserver/traffic_server(_ZN14CacheProcessor15diskInitializedEv+0x323)[0x827e0d3]
trafficserver/traffic_server(_ZN9CacheDisk9openStartEiPv+0x483)[0x828c9c3]
trafficserver/traffic_server(_ZN19AIOCallbackInternal11io_completeEiPv+0x25)[0x8280a75]
trafficserver/traffic_server(_ZN7EThread13process_eventEP5Eventi+0x8b)[0x830343b]
trafficserver/traffic_server(_ZN7EThread7executeEv+0x723)[0x8304003]
trafficserver/traffic_server(main+0x178d)[0x80c572d]
/lib/i386-linux-gnu/i686/cmov/libc.so.6(__libc_start_main+0xe6)[0xb7039e46]
trafficserver/traffic_server[0x80cabdd]
administrator@debian:~$
{code}
ats_memalign: couldn't allocate -548249600 bytes in Vol::init()
---
Key: TS-1528
URL: https://issues.apache.org/jira/browse/TS-1528
Project: Traffic Server
Issue Type: Bug
Affects Versions: 3.2.0
Environment: Debian testing (wheezy) on i686
Reporter: Jack Bates
I consistently get the following error whenever I try to start Traffic Server
(release 3.2.0). Yesterday I built Traffic Server from Git HEAD (34a2ba) to
check if it behaves any differently, but I consistently reproduce this same
error whenever I try to start it, too
Here's my configuration, which is pretty minimal:
http://nottheoilrig.com/trafficserver/201210120/
What details can I provide to help debug this? James Peach suggested
attaching some kind of dump of the volume header:
http://mail-archives.apache.org/mod_mbox/trafficserver-users/201210.mbox/%3C9ED91AE2-2F52-4BDB-9088-E14D40642C34%40apache.org%3E
{code}
administrator@debian$ TS_ROOT=/home/administrator/trafficserver
trafficserver/traffic_server
[TrafficServer] using root directory '/home/administrator/trafficserver'
FATAL:
