[jira] [Commented] (TS-3710) Crash in TLS with 6.0.0, related to the session cleanup additions
[
https://issues.apache.org/jira/browse/TS-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14632765#comment-14632765
]
Leif Hedstrom commented on TS-3710:
---
If you want to, we can restore the patch that was reverted due to this. With
that patch active, it was crashing very, very frequently (10+ times / day on a
low traffic server). As @amc has pointed out before, it's possible that was a
red herring, and only made an pre-existing condition worse.
Crash in TLS with 6.0.0, related to the session cleanup additions
-
Key: TS-3710
URL: https://issues.apache.org/jira/browse/TS-3710
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 5.3.0
Reporter: Leif Hedstrom
Assignee: Susan Hinrichs
Priority: Critical
Labels: yahoo
Fix For: 6.1.0
Attachments: ts-3710-2.diff, ts-3710-final-2.diff, ts-3710.diff
{code}
==9570==ERROR: AddressSanitizer: heap-use-after-free on address
0x60649f48 at pc 0xb9f969 bp 0x2b8dbc348920 sp 0x2b8dbc348918
READ of size 8 at 0x60649f48 thread T8 ([ET_NET 7])
#0 0xb9f968 in Continuation::handleEvent(int, void*)
../../iocore/eventsystem/I_Continuation.h:145
#1 0xb9f968 in read_signal_and_update
/usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:142
#2 0xb9f968 in UnixNetVConnection::mainEvent(int, Event*)
/usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:1115
#3 0xb7daf7 in Continuation::handleEvent(int, void*)
../../iocore/eventsystem/I_Continuation.h:145
#4 0xb7daf7 in InactivityCop::check_inactivity(int, Event*)
/usr/local/src/trafficserver/iocore/net/UnixNet.cc:102
#5 0xc21ffe in Continuation::handleEvent(int, void*)
/usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:145
#6 0xc21ffe in EThread::process_event(Event*, int)
/usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:128
#7 0xc241f7 in EThread::execute()
/usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:207
#8 0xc20c18 in spawn_thread_internal
/usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:85
#9 0x2b8db3ff6df4 in start_thread (/lib64/libpthread.so.0+0x7df4)
#10 0x2b8db585f1ac in __clone (/lib64/libc.so.6+0xf61ac)
0x60649f48 is located 8 bytes inside of 56-byte region
[0x60649f40,0x60649f78)
freed by thread T8 ([ET_NET 7]) here:
#0 0x2b8db1bf3117 in operator delete(void*)
../../.././libsanitizer/asan/asan_new_delete.cc:81
#1 0xb5b20e in SSLNextProtocolTrampoline::ioCompletionEvent(int, void*)
/usr/local/src/trafficserver/iocore/net/SSLNextProtocolAccept.cc:89
#2 0xbb2eef in Continuation::handleEvent(int, void*)
../../iocore/eventsystem/I_Continuation.h:145
#3 0xbb2eef in read_signal_and_update
/usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:142
#4 0xbb2eef in read_signal_done
/usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:203
#5 0xbb2eef in UnixNetVConnection::readSignalDone(int, NetHandler*)
/usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:957
#6 0xb55d6d in SSLNetVConnection::net_read_io(NetHandler*, EThread*)
/usr/local/src/trafficserver/iocore/net/SSLNetVConnection.cc:480
#7 0xb748fc in NetHandler::mainNetEvent(int, Event*)
/usr/local/src/trafficserver/iocore/net/UnixNet.cc:516
#8 0xc24e89 in Continuation::handleEvent(int, void*)
/usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:145
#9 0xc24e89 in EThread::process_event(Event*, int)
/usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:128
#10 0xc24e89 in EThread::execute()
/usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:252
#11 0xc20c18 in spawn_thread_internal
/usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:85
#12 0x2b8db3ff6df4 in start_thread (/lib64/libpthread.so.0+0x7df4)
previously allocated by thread T8 ([ET_NET 7]) here:
#0 0x2b8db1bf2c9f in operator new(unsigned long)
../../.././libsanitizer/asan/asan_new_delete.cc:50
#1 0xb59f8b in SSLNextProtocolAccept::mainEvent(int, void*)
/usr/local/src/trafficserver/iocore/net/SSLNextProtocolAccept.cc:134
#2 0xb888e9 in Continuation::handleEvent(int, void*)
../../iocore/eventsystem/I_Continuation.h:145
#3 0xb888e9 in NetAccept::acceptFastEvent(int, void*)
/usr/local/src/trafficserver/iocore/net/UnixNetAccept.cc:466
#4 0xc24e89 in Continuation::handleEvent(int, void*)
/usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:145
#5 0xc24e89 in EThread::process_event(Event*, int)
/usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:128
#6 0xc24e89 in EThread::execute()
[jira] [Comment Edited] (TS-3710) Crash in TLS with 6.0.0, related to the session cleanup additions
[
https://issues.apache.org/jira/browse/TS-3710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14632765#comment-14632765
]
Leif Hedstrom edited comment on TS-3710 at 7/19/15 10:10 AM:
-
If you want to, we can restore the patch that was reverted due to this, add any
changes to fix this, and run this on docs.trafficserver.apache.org . With that
previous patch active, it was crashing very, very frequently (10+ times / day
on a low traffic server). As @amc has pointed out before, it's possible that
was a red herring, and only made an pre-existing condition worse.
was (Author: zwoop):
If you want to, we can restore the patch that was reverted due to this. With
that patch active, it was crashing very, very frequently (10+ times / day on a
low traffic server). As @amc has pointed out before, it's possible that was a
red herring, and only made an pre-existing condition worse.
Crash in TLS with 6.0.0, related to the session cleanup additions
-
Key: TS-3710
URL: https://issues.apache.org/jira/browse/TS-3710
Project: Traffic Server
Issue Type: Bug
Components: SSL
Affects Versions: 5.3.0
Reporter: Leif Hedstrom
Assignee: Susan Hinrichs
Priority: Critical
Labels: yahoo
Fix For: 6.1.0
Attachments: ts-3710-2.diff, ts-3710-final-2.diff, ts-3710.diff
{code}
==9570==ERROR: AddressSanitizer: heap-use-after-free on address
0x60649f48 at pc 0xb9f969 bp 0x2b8dbc348920 sp 0x2b8dbc348918
READ of size 8 at 0x60649f48 thread T8 ([ET_NET 7])
#0 0xb9f968 in Continuation::handleEvent(int, void*)
../../iocore/eventsystem/I_Continuation.h:145
#1 0xb9f968 in read_signal_and_update
/usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:142
#2 0xb9f968 in UnixNetVConnection::mainEvent(int, Event*)
/usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:1115
#3 0xb7daf7 in Continuation::handleEvent(int, void*)
../../iocore/eventsystem/I_Continuation.h:145
#4 0xb7daf7 in InactivityCop::check_inactivity(int, Event*)
/usr/local/src/trafficserver/iocore/net/UnixNet.cc:102
#5 0xc21ffe in Continuation::handleEvent(int, void*)
/usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:145
#6 0xc21ffe in EThread::process_event(Event*, int)
/usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:128
#7 0xc241f7 in EThread::execute()
/usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:207
#8 0xc20c18 in spawn_thread_internal
/usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:85
#9 0x2b8db3ff6df4 in start_thread (/lib64/libpthread.so.0+0x7df4)
#10 0x2b8db585f1ac in __clone (/lib64/libc.so.6+0xf61ac)
0x60649f48 is located 8 bytes inside of 56-byte region
[0x60649f40,0x60649f78)
freed by thread T8 ([ET_NET 7]) here:
#0 0x2b8db1bf3117 in operator delete(void*)
../../.././libsanitizer/asan/asan_new_delete.cc:81
#1 0xb5b20e in SSLNextProtocolTrampoline::ioCompletionEvent(int, void*)
/usr/local/src/trafficserver/iocore/net/SSLNextProtocolAccept.cc:89
#2 0xbb2eef in Continuation::handleEvent(int, void*)
../../iocore/eventsystem/I_Continuation.h:145
#3 0xbb2eef in read_signal_and_update
/usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:142
#4 0xbb2eef in read_signal_done
/usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:203
#5 0xbb2eef in UnixNetVConnection::readSignalDone(int, NetHandler*)
/usr/local/src/trafficserver/iocore/net/UnixNetVConnection.cc:957
#6 0xb55d6d in SSLNetVConnection::net_read_io(NetHandler*, EThread*)
/usr/local/src/trafficserver/iocore/net/SSLNetVConnection.cc:480
#7 0xb748fc in NetHandler::mainNetEvent(int, Event*)
/usr/local/src/trafficserver/iocore/net/UnixNet.cc:516
#8 0xc24e89 in Continuation::handleEvent(int, void*)
/usr/local/src/trafficserver/iocore/eventsystem/I_Continuation.h:145
#9 0xc24e89 in EThread::process_event(Event*, int)
/usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:128
#10 0xc24e89 in EThread::execute()
/usr/local/src/trafficserver/iocore/eventsystem/UnixEThread.cc:252
#11 0xc20c18 in spawn_thread_internal
/usr/local/src/trafficserver/iocore/eventsystem/Thread.cc:85
#12 0x2b8db3ff6df4 in start_thread (/lib64/libpthread.so.0+0x7df4)
previously allocated by thread T8 ([ET_NET 7]) here:
#0 0x2b8db1bf2c9f in operator new(unsigned long)
../../.././libsanitizer/asan/asan_new_delete.cc:50
#1 0xb59f8b in SSLNextProtocolAccept::mainEvent(int, void*)
/usr/local/src/trafficserver/iocore/net/SSLNextProtocolAccept.cc:134
#2 0xb888e9 in Continuation::handleEvent(int, void*)
[jira] [Commented] (TS-3746) We need to make proxy.config.ssl.client.verify.server overridable
[ https://issues.apache.org/jira/browse/TS-3746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14632775#comment-14632775 ] ASF GitHub Bot commented on TS-3746: Github user zwoop commented on the pull request: https://github.com/apache/trafficserver/pull/254#issuecomment-122645818 I have a few concerns with the code here actually. In general, we want more configurations overridable, including cache configurations and network configurations. I tried this once before, and it got -1'd for other reasons (cache clustering). What I'm asking for is, is there some better way we can convey the entire oride object back to other areas of the system, such as the network layers and cache layers ? It wouldn't be particular efficient to do many of these special cases going forward. Also, there's some legitimate concerns here re: this being a generally good idea, or a fix for an organizational issue. I'll have to noodle on that a bit more (my gut tells me, if you want to enable cert verification for one set of servers, is it that much more work to do it for all servers?). That much said, a few comments on the patch itself: 1) I think ssl_client_verify_server should be a MgmtByte, moved up to the section of those (to avoid padding), and of course use HttpEstablishStaticConfigByte() to for loading. 2) I don't think this patch was run through clang-format, the indentation doesn't look right. 3) Similarly to 1), but on line 1062 in HttpSM, we introduce two empty lines, with 2 white spaces? We need to make proxy.config.ssl.client.verify.server overridable - Key: TS-3746 URL: https://issues.apache.org/jira/browse/TS-3746 Project: Traffic Server Issue Type: New Feature Components: Configuration Reporter: Syeda Persia Aziz Assignee: Dave Thompson Labels: Yahoo Fix For: sometime We need to make proxy.config.ssl.client.verify.server overridable. Some origin servers need validation to avoid MITM attacks while others don't. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-974) TS should have a mode to hold partial objects in cache
[ https://issues.apache.org/jira/browse/TS-974?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14632814#comment-14632814 ] ASF subversion and git services commented on TS-974: Commit 1c06db83123c336d462083002eda9ffcd4852730 in trafficserver's branch refs/heads/poc-6-0-x from [~amc] [ https://git-wip-us.apache.org/repos/asf?p=trafficserver.git;h=1c06db8 ] TS-974: Partial Object Caching. TS should have a mode to hold partial objects in cache -- Key: TS-974 URL: https://issues.apache.org/jira/browse/TS-974 Project: Traffic Server Issue Type: Improvement Components: Cache Affects Versions: 3.0.1 Reporter: William Bardwell Assignee: Alan M. Carroll Labels: A Fix For: 6.1.0 For ATS to do an excelent job caching large files like video it would need to be able to hold partial objects for a large file. This could be done in a plugin or in the core. This would need to be integrated with the Range handling code to serve requests out of the partial objects and to get more parts of a file to satisfy a Range request. An intermediate step (also do-able in the core or in a plugin) would be to have some settings to let the Range handling code be able to trigger a full file download either asynchronously when a Range response indicates that the file isn't larger than some threshold, or synchronously when a Range request could reasonably be answered quickly from a full request. (Right now Range requests are tunneled if there is not full cached content as far as I can tell.) -- This message was sent by Atlassian JIRA (v6.3.4#6332)
