[jira] [Commented] (TS-2564) Segmentation fault in 4.2.0-rc0
[
https://issues.apache.org/jira/browse/TS-2564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091802#comment-14091802
]
ASF subversion and git services commented on TS-2564:
-
Commit 8141ceae283a9bca5cb1d6830c11a0acccdd86d6 in trafficserver's branch
refs/heads/master from [~amc]
[ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=8141cea ]
Cherry-pick - TS-2564: Fixup MIME presence bits and slot accelerators to
recover from WKS_IDX changes, plus config to turn it off manually.
Segmentation fault in 4.2.0-rc0
---
Key: TS-2564
URL: https://issues.apache.org/jira/browse/TS-2564
Project: Traffic Server
Issue Type: Bug
Components: HTTP
Reporter: Bryan Call
Assignee: Phil Sorber
Priority: Blocker
Labels: crash
Fix For: 4.2.1, 5.0.0
Attachments: ts-2564-B.diff, ts-2564.diff
Segmentation fault in mime_hdr_set_accelerators_and_presence_bits() in
4.2.0-rc0:
{code}
(gdb) bt
#0 mime_hdr_set_accelerators_and_presence_bits (mh=0x2acd02e108c8,
field=value optimized out, detach_all_dups=false) at MIME.cc:469
#1 mime_hdr_field_detach (mh=0x2acd02e108c8, field=value optimized out,
detach_all_dups=false) at MIME.cc:1538
#2 0x005c322c in mime_hdr_field_delete (heap=0x2acd02e10810,
mh=0x2acd02e108c8, field=0x2acd02e10ab8, delete_all_dups=value optimized
out) at MIME.cc:1586
#3 0x0053cb5b in field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1107
#4 field_delete (cached_header=0x2acde002fa40,
response_header=0x2accc168b1d8) at ../../proxy/hdrs/MIME.h:1115
#5 HttpTransact::merge_response_header_with_cached_header
(cached_header=0x2acde002fa40, response_header=0x2accc168b1d8) at
HttpTransact.cc:4914
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (TS-2362) Backwards cache compatibility for 4.X (read 3.2)
[ https://issues.apache.org/jira/browse/TS-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091801#comment-14091801 ] ASF subversion and git services commented on TS-2362: - Commit d6bcd2d90e0bd7494a14375a45a413974158676f in trafficserver's branch refs/heads/master from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=d6bcd2d ] TS-2362: Cache backwards compatibility to 3.2.0. Backwards cache compatibility for 4.X (read 3.2) Key: TS-2362 URL: https://issues.apache.org/jira/browse/TS-2362 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Alan M. Carroll Assignee: Alan M. Carroll Labels: Review Fix For: 5.1.0 Attachments: ts-2362.diff Enable the 4.X series to be able to read 3.2 caches. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-2362) Backwards cache compatibility for 4.X (read 3.2)
[ https://issues.apache.org/jira/browse/TS-2362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091821#comment-14091821 ] Alan M. Carroll commented on TS-2362: - Final result - This change requires no configuration, it should just work. That is, if you install a version with this change then your old cache should be maintained. This applies back to version 3.2.0 - and upgrade from that or later version should preserve the cache. Note that any cache updates are written in the current format, not the old format. Over time this should cause a cache to be updated to the newest version. Because this is now tracked per object, the cost of backwards compatibility should diminish over time as new objects are updated and the compatibility logic can easily detect that to be the case. I incorporated the TS-2564. Previously this fix had been left on the 4.2.X branch because (since 5.0 had a different cache version) it wasn't needed. However, as this enables using 4.2.X caches of all formats we must be able to do that fix up as well. Again, as per above, while the fixup will be done on all objects, new/updatd objects will skip the fixup because the object being permanently fixed is now trivial to detect. Backwards cache compatibility for 4.X (read 3.2) Key: TS-2362 URL: https://issues.apache.org/jira/browse/TS-2362 Project: Traffic Server Issue Type: Improvement Components: Cache Reporter: Alan M. Carroll Assignee: Alan M. Carroll Labels: Review Fix For: 5.1.0 Attachments: ts-2362.diff Enable the 4.X series to be able to read 3.2 caches. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (TS-1475) static analysis: clean up all clang and coverity reports
[ https://issues.apache.org/jira/browse/TS-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14091824#comment-14091824 ] ASF subversion and git services commented on TS-1475: - Commit 9bce6843873467eb251ff25e05921925ab8cbaee in trafficserver's branch refs/heads/master from [~psudaemon] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=9bce684 ] TS-1475: Merge libck master (0.4.3-4-g20f0827) to fix clang warning static analysis: clean up all clang and coverity reports Key: TS-1475 URL: https://issues.apache.org/jira/browse/TS-1475 Project: Traffic Server Issue Type: Bug Components: Cleanup Affects Versions: 3.3.0 Reporter: Zhao Yongming Fix For: sometime the new report is in https://ci.trafficserver.apache.org/files/clang-analyzer/latest/ -- 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)
