[jira] [Work logged] (TS-4858) Global session ticket key block leaks.
[ https://issues.apache.org/jira/browse/TS-4858?focusedWorklogId=30184=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30184 ] ASF GitHub Bot logged work on TS-4858: -- Author: ASF GitHub Bot Created on: 05/Oct/16 17:59 Start Date: 05/Oct/16 17:59 Worklog Time Spent: 10m Work Description: Github user persiaAziz commented on the issue: https://github.com/apache/trafficserver/pull/1024 Please review @shinrich Issue Time Tracking --- Worklog Id: (was: 30184) Time Spent: 1h 10m (was: 1h) > Global session ticket key block leaks. > -- > > Key: TS-4858 > URL: https://issues.apache.org/jira/browse/TS-4858 > Project: Traffic Server > Issue Type: Bug > Components: SSL >Reporter: James Peach >Assignee: Syeda Persia Aziz > Fix For: 7.1.0 > > Time Spent: 1h 10m > Remaining Estimate: 0h > > From source inspection, ``global_default_keyblock`` is always assigned so it > will leak on configuration reload. > Have not reproduced this since I wasn't able to get SSL config reload to work > :-( -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #1024: TS-4858: fix memory leak of global_default_keyblo...
Github user persiaAziz commented on the issue: https://github.com/apache/trafficserver/pull/1024 Please review @shinrich --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Work logged] (TS-4929) Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled)
[ https://issues.apache.org/jira/browse/TS-4929?focusedWorklogId=30183=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30183 ] ASF GitHub Bot logged work on TS-4929: -- Author: ASF GitHub Bot Created on: 05/Oct/16 15:53 Start Date: 05/Oct/16 15:53 Worklog Time Spent: 10m Work Description: Github user jpeach commented on the issue: https://github.com/apache/trafficserver/pull/1076 OK that sounds reasonable. Issue Time Tracking --- Worklog Id: (was: 30183) Time Spent: 1h (was: 50m) > Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled) > > > Key: TS-4929 > URL: https://issues.apache.org/jira/browse/TS-4929 > Project: Traffic Server > Issue Type: Improvement > Components: HostDB >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 7.1.0 > > Time Spent: 1h > Remaining Estimate: 0h > > This addresses two issues: > 1) We get warnings trying to load a non-existent HostDB (since we don't sync > it). > 2) Worse, if someone has an old HostDB, that is no longer synced / updated, > we load the old, possibly stale, data on every startup. > #2 seems inconsistent with the other changes to HostDB, where now the sync > frequency =0 truly turns off disk syncing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #1076: TS-4929: No loading of HostDB disk file if sync_f...
Github user jpeach commented on the issue: https://github.com/apache/trafficserver/pull/1076 OK that sounds reasonable. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Work logged] (TS-4929) Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled)
[ https://issues.apache.org/jira/browse/TS-4929?focusedWorklogId=30182=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30182 ] ASF GitHub Bot logged work on TS-4929: -- Author: ASF GitHub Bot Created on: 05/Oct/16 15:49 Start Date: 05/Oct/16 15:49 Worklog Time Spent: 10m Work Description: Github user zwoop commented on the issue: https://github.com/apache/trafficserver/pull/1076 Yes, they would have TTLs, but if I turned off syncing, I certainly wouldn't expect it to load something old. What if I had bad entries? What if I had a corruption of some sort? Since it will never update it, you are stuck with loading old (possibly stale or more likely expired) entries for the remaining of life? That just makes no sense. Issue Time Tracking --- Worklog Id: (was: 30182) Time Spent: 50m (was: 40m) > Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled) > > > Key: TS-4929 > URL: https://issues.apache.org/jira/browse/TS-4929 > Project: Traffic Server > Issue Type: Improvement > Components: HostDB >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 7.1.0 > > Time Spent: 50m > Remaining Estimate: 0h > > This addresses two issues: > 1) We get warnings trying to load a non-existent HostDB (since we don't sync > it). > 2) Worse, if someone has an old HostDB, that is no longer synced / updated, > we load the old, possibly stale, data on every startup. > #2 seems inconsistent with the other changes to HostDB, where now the sync > frequency =0 truly turns off disk syncing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #1076: TS-4929: No loading of HostDB disk file if sync_f...
Github user zwoop commented on the issue: https://github.com/apache/trafficserver/pull/1076 Yes, they would have TTLs, but if I turned off syncing, I certainly wouldn't expect it to load something old. What if I had bad entries? What if I had a corruption of some sort? Since it will never update it, you are stuck with loading old (possibly stale or more likely expired) entries for the remaining of life? That just makes no sense. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Commented] (TS-4578) Skip HostDB lookup for all address literals
[
https://issues.apache.org/jira/browse/TS-4578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15549098#comment-15549098
]
James Peach commented on TS-4578:
-
Wai, I opened this? I wonder why I did that? On further investigation, the IP
address literal is handled in {{HostDBContinuation::do_dns()}}, so other than
for the performance claim in TS-3366, I'm not sure there is a good reason to
do this.
> Skip HostDB lookup for all address literals
> ---
>
> Key: TS-4578
> URL: https://issues.apache.org/jira/browse/TS-4578
> Project: Traffic Server
> Issue Type: Improvement
> Components: Core, DNS
>Reporter: James Peach
>Assignee: David Ben Zakai
> Labels: newbie
> Fix For: sometime
>
> Time Spent: 10m
> Remaining Estimate: 0h
>
> In {{HttpSM.cc}}:
> {code}
> if ((strncmp(t_state.dns_info.lookup_name, "127.0.0.1", 9) == 0 ||
> strncmp(t_state.dns_info.lookup_name, "::1", 3) == 0) &&
> ats_ip_pton(t_state.dns_info.lookup_name, t_state.host_db_info.ip())
> == 0) {
> // If it's 127.0.0.1 or ::1 don't bother with hostdb
> DebugSM("dns", "[HttpTransact::HandleRequest] Skipping DNS lookup for
> %s because it's loopback",
> t_state.dns_info.lookup_name);
> t_state.dns_info.lookup_success = true;
> call_transact_and_set_next_state(NULL);
> break;
> {code}
> There's no reason to restrict address literals to loopback. It seems like we
> should be able to do this for all address literals.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4937) Evaluate HostLookup code for SSL certificate matching.
James Peach created TS-4937: --- Summary: Evaluate HostLookup code for SSL certificate matching. Key: TS-4937 URL: https://issues.apache.org/jira/browse/TS-4937 Project: Traffic Server Issue Type: Bug Reporter: James Peach -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Work logged] (TS-4929) Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled)
[ https://issues.apache.org/jira/browse/TS-4929?focusedWorklogId=30181=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30181 ] ASF GitHub Bot logged work on TS-4929: -- Author: ASF GitHub Bot Created on: 05/Oct/16 15:26 Start Date: 05/Oct/16 15:26 Worklog Time Spent: 10m Work Description: Github user jpeach commented on the issue: https://github.com/apache/trafficserver/pull/1076 @zwoop (1) and (2) sound like they are in conflict? I'm confused about whether it loads or not? If it does load, do you really have a stale record problem, since each record has a TTL? Issue Time Tracking --- Worklog Id: (was: 30181) Time Spent: 40m (was: 0.5h) > Should we avoid loading HostDB disk file is sync_frequency is '0' (disabled) > > > Key: TS-4929 > URL: https://issues.apache.org/jira/browse/TS-4929 > Project: Traffic Server > Issue Type: Improvement > Components: HostDB >Reporter: Leif Hedstrom >Assignee: Leif Hedstrom > Fix For: 7.1.0 > > Time Spent: 40m > Remaining Estimate: 0h > > This addresses two issues: > 1) We get warnings trying to load a non-existent HostDB (since we don't sync > it). > 2) Worse, if someone has an old HostDB, that is no longer synced / updated, > we load the old, possibly stale, data on every startup. > #2 seems inconsistent with the other changes to HostDB, where now the sync > frequency =0 truly turns off disk syncing. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[GitHub] trafficserver issue #1076: TS-4929: No loading of HostDB disk file if sync_f...
Github user jpeach commented on the issue: https://github.com/apache/trafficserver/pull/1076 @zwoop (1) and (2) sound like they are in conflict? I'm confused about whether it loads or not? If it does load, do you really have a stale record problem, since each record has a TTL? --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[GitHub] trafficserver issue #1052: TS-4813: Fix lingering stream.
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/1052 FreeBSD build *successful*! See https://ci.trafficserver.apache.org/job/Github-FreeBSD/937/ for details. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Work logged] (TS-4813) HttpTunnel.cc:1215: failed assertion `p->alive == true || event == HTTP_TUNNEL_EVENT_PRECOMPLETE ...
[
https://issues.apache.org/jira/browse/TS-4813?focusedWorklogId=30180=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30180
]
ASF GitHub Bot logged work on TS-4813:
--
Author: ASF GitHub Bot
Created on: 05/Oct/16 15:16
Start Date: 05/Oct/16 15:16
Worklog Time Spent: 10m
Work Description: Github user atsci commented on the issue:
https://github.com/apache/trafficserver/pull/1052
FreeBSD build *successful*! See
https://ci.trafficserver.apache.org/job/Github-FreeBSD/937/ for details.
Issue Time Tracking
---
Worklog Id: (was: 30180)
Time Spent: 4h 50m (was: 4h 40m)
> HttpTunnel.cc:1215: failed assertion `p->alive == true || event ==
> HTTP_TUNNEL_EVENT_PRECOMPLETE ...
>
>
> Key: TS-4813
> URL: https://issues.apache.org/jira/browse/TS-4813
> Project: Traffic Server
> Issue Type: Bug
> Components: Network
>Reporter: Leif Hedstrom
>Priority: Blocker
> Labels: crash
> Fix For: 7.1.0
>
> Time Spent: 4h 50m
> Remaining Estimate: 0h
>
> Seeing this with current (as of right now) master, on docs.trafficserver:
> {code}
> FATAL: HttpTunnel.cc:1215: failed assertion `p->alive == true || event ==
> HTTP_TUNNEL_EVENT_PRECOMPLETE || event == VC_EVENT_EOS ||
> sm->enable_redirection || (p->self_consumer && p->self_consumer->alive ==
> true)`
> traffic_server: using root directory '/opt/ats'
> traffic_server: Aborted (Signal sent by tkill() 13188 99)
> traffic_server - STACK TRACE:
> /opt/ats/lib/libtsutil.so.7(signal_crash_handler(int, siginfo_t*,
> void*)+0x18)[0x2b6d1031729e]
> /opt/ats/bin/traffic_server(crash_logger_invoke(int, siginfo_t*,
> void*)+0x155)[0x534104]
> /lib64/libpthread.so.0(+0xf100)[0x2b6d1240f100]
> /lib64/libc.so.6(gsignal+0x37)[0x2b6d12d6e5f7]
> /lib64/libc.so.6(abort+0x148)[0x2b6d12d6fce8]
> /opt/ats/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2b6d102f6f4d]
> /opt/ats/lib/libtsutil.so.7(+0x733a7)[0x2b6d102f13a7]
> /opt/ats/bin/traffic_server(HttpTunnel::producer_handler(int,
> HttpTunnelProducer*)+0xd14)[0x768a12]
> /opt/ats/bin/traffic_server(HttpTunnel::main_handler(int,
> void*)+0x13b)[0x76b6e1]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(HttpSM::state_watch_for_client_abort(int,
> void*)+0x9fe)[0x68c5e6]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0x58e)[0x69b7ec]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(Http2Stream::main_event_handler(int,
> void*)+0x59f)[0x79c1df]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*,
> int)+0x2cf)[0xa809fb]
> /opt/ats/bin/traffic_server(EThread::execute()+0x671)[0xa8140f]
> /opt/ats/bin/traffic_server[0xa7f407]
> /lib64/libpthread.so.0(+0x7dc5)[0x2b6d12407dc5]
> /lib64/libc.so.6(clone+0x6d)[0x2b6d12e2fced]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Work logged] (TS-4813) HttpTunnel.cc:1215: failed assertion `p->alive == true || event == HTTP_TUNNEL_EVENT_PRECOMPLETE ...
[
https://issues.apache.org/jira/browse/TS-4813?focusedWorklogId=30179=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30179
]
ASF GitHub Bot logged work on TS-4813:
--
Author: ASF GitHub Bot
Created on: 05/Oct/16 15:09
Start Date: 05/Oct/16 15:09
Worklog Time Spent: 10m
Work Description: Github user atsci commented on the issue:
https://github.com/apache/trafficserver/pull/1052
Linux build *failed*! See
https://ci.trafficserver.apache.org/job/Github-Linux/829/ for details.
Issue Time Tracking
---
Worklog Id: (was: 30179)
Time Spent: 4h 40m (was: 4.5h)
> HttpTunnel.cc:1215: failed assertion `p->alive == true || event ==
> HTTP_TUNNEL_EVENT_PRECOMPLETE ...
>
>
> Key: TS-4813
> URL: https://issues.apache.org/jira/browse/TS-4813
> Project: Traffic Server
> Issue Type: Bug
> Components: Network
>Reporter: Leif Hedstrom
>Priority: Blocker
> Labels: crash
> Fix For: 7.1.0
>
> Time Spent: 4h 40m
> Remaining Estimate: 0h
>
> Seeing this with current (as of right now) master, on docs.trafficserver:
> {code}
> FATAL: HttpTunnel.cc:1215: failed assertion `p->alive == true || event ==
> HTTP_TUNNEL_EVENT_PRECOMPLETE || event == VC_EVENT_EOS ||
> sm->enable_redirection || (p->self_consumer && p->self_consumer->alive ==
> true)`
> traffic_server: using root directory '/opt/ats'
> traffic_server: Aborted (Signal sent by tkill() 13188 99)
> traffic_server - STACK TRACE:
> /opt/ats/lib/libtsutil.so.7(signal_crash_handler(int, siginfo_t*,
> void*)+0x18)[0x2b6d1031729e]
> /opt/ats/bin/traffic_server(crash_logger_invoke(int, siginfo_t*,
> void*)+0x155)[0x534104]
> /lib64/libpthread.so.0(+0xf100)[0x2b6d1240f100]
> /lib64/libc.so.6(gsignal+0x37)[0x2b6d12d6e5f7]
> /lib64/libc.so.6(abort+0x148)[0x2b6d12d6fce8]
> /opt/ats/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2b6d102f6f4d]
> /opt/ats/lib/libtsutil.so.7(+0x733a7)[0x2b6d102f13a7]
> /opt/ats/bin/traffic_server(HttpTunnel::producer_handler(int,
> HttpTunnelProducer*)+0xd14)[0x768a12]
> /opt/ats/bin/traffic_server(HttpTunnel::main_handler(int,
> void*)+0x13b)[0x76b6e1]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(HttpSM::state_watch_for_client_abort(int,
> void*)+0x9fe)[0x68c5e6]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0x58e)[0x69b7ec]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(Http2Stream::main_event_handler(int,
> void*)+0x59f)[0x79c1df]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*,
> int)+0x2cf)[0xa809fb]
> /opt/ats/bin/traffic_server(EThread::execute()+0x671)[0xa8140f]
> /opt/ats/bin/traffic_server[0xa7f407]
> /lib64/libpthread.so.0(+0x7dc5)[0x2b6d12407dc5]
> /lib64/libc.so.6(clone+0x6d)[0x2b6d12e2fced]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver issue #1052: TS-4813: Fix lingering stream.
Github user atsci commented on the issue: https://github.com/apache/trafficserver/pull/1052 Linux build *failed*! See https://ci.trafficserver.apache.org/job/Github-Linux/829/ for details. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Work logged] (TS-4813) HttpTunnel.cc:1215: failed assertion `p->alive == true || event == HTTP_TUNNEL_EVENT_PRECOMPLETE ...
[
https://issues.apache.org/jira/browse/TS-4813?focusedWorklogId=30178=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30178
]
ASF GitHub Bot logged work on TS-4813:
--
Author: ASF GitHub Bot
Created on: 05/Oct/16 15:07
Start Date: 05/Oct/16 15:07
Worklog Time Spent: 10m
Work Description: Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1052
Pushed up a squashed, tidied up branch. Running a build on this for a bit
to make sure I didn't mess anything up in the tidy.
Issue Time Tracking
---
Worklog Id: (was: 30178)
Time Spent: 4.5h (was: 4h 20m)
> HttpTunnel.cc:1215: failed assertion `p->alive == true || event ==
> HTTP_TUNNEL_EVENT_PRECOMPLETE ...
>
>
> Key: TS-4813
> URL: https://issues.apache.org/jira/browse/TS-4813
> Project: Traffic Server
> Issue Type: Bug
> Components: Network
>Reporter: Leif Hedstrom
>Priority: Blocker
> Labels: crash
> Fix For: 7.1.0
>
> Time Spent: 4.5h
> Remaining Estimate: 0h
>
> Seeing this with current (as of right now) master, on docs.trafficserver:
> {code}
> FATAL: HttpTunnel.cc:1215: failed assertion `p->alive == true || event ==
> HTTP_TUNNEL_EVENT_PRECOMPLETE || event == VC_EVENT_EOS ||
> sm->enable_redirection || (p->self_consumer && p->self_consumer->alive ==
> true)`
> traffic_server: using root directory '/opt/ats'
> traffic_server: Aborted (Signal sent by tkill() 13188 99)
> traffic_server - STACK TRACE:
> /opt/ats/lib/libtsutil.so.7(signal_crash_handler(int, siginfo_t*,
> void*)+0x18)[0x2b6d1031729e]
> /opt/ats/bin/traffic_server(crash_logger_invoke(int, siginfo_t*,
> void*)+0x155)[0x534104]
> /lib64/libpthread.so.0(+0xf100)[0x2b6d1240f100]
> /lib64/libc.so.6(gsignal+0x37)[0x2b6d12d6e5f7]
> /lib64/libc.so.6(abort+0x148)[0x2b6d12d6fce8]
> /opt/ats/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2b6d102f6f4d]
> /opt/ats/lib/libtsutil.so.7(+0x733a7)[0x2b6d102f13a7]
> /opt/ats/bin/traffic_server(HttpTunnel::producer_handler(int,
> HttpTunnelProducer*)+0xd14)[0x768a12]
> /opt/ats/bin/traffic_server(HttpTunnel::main_handler(int,
> void*)+0x13b)[0x76b6e1]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(HttpSM::state_watch_for_client_abort(int,
> void*)+0x9fe)[0x68c5e6]
> /opt/ats/bin/traffic_server(HttpSM::main_handler(int, void*)+0x58e)[0x69b7ec]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(Http2Stream::main_event_handler(int,
> void*)+0x59f)[0x79c1df]
> /opt/ats/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x149)[0x53a621]
> /opt/ats/bin/traffic_server(EThread::process_event(Event*,
> int)+0x2cf)[0xa809fb]
> /opt/ats/bin/traffic_server(EThread::execute()+0x671)[0xa8140f]
> /opt/ats/bin/traffic_server[0xa7f407]
> /lib64/libpthread.so.0(+0x7dc5)[0x2b6d12407dc5]
> /lib64/libc.so.6(clone+0x6d)[0x2b6d12e2fced]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver issue #1052: TS-4813: Fix lingering stream.
Github user shinrich commented on the issue: https://github.com/apache/trafficserver/pull/1052 Pushed up a squashed, tidied up branch. Running a build on this for a bit to make sure I didn't mess anything up in the tidy. --- If your project is set up for it, you can reply to this email and have your reply appear on GitHub as well. If your project does not have this feature enabled and wishes so, or if the feature is enabled but not working, please contact infrastructure at infrastruct...@apache.org or file a JIRA ticket with INFRA. ---
[jira] [Work logged] (TS-4905) Crash when slow logging is enabled.
[
https://issues.apache.org/jira/browse/TS-4905?focusedWorklogId=30173=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30173
]
ASF GitHub Bot logged work on TS-4905:
--
Author: ASF GitHub Bot
Created on: 05/Oct/16 14:35
Start Date: 05/Oct/16 14:35
Worklog Time Spent: 10m
Work Description: Github user shinrich commented on a diff in the pull
request:
https://github.com/apache/trafficserver/pull/1075#discussion_r81987102
--- Diff: proxy/http/Http1ClientTransaction.cc ---
@@ -67,6 +67,7 @@ Http1ClientTransaction::transaction_done()
// If the parent session is not in the closed state, the destroy will
not occur.
if (parent) {
parent->destroy();
+parent = NULL;
--- End diff --
Yes, destroy doesn't necessarily destroy. But from transaction_done(), the
client transaction is done with the parent session. So even if the parent is
still around, the client transaction should no longer be manipulating it.
The change looks good to me.
Issue Time Tracking
---
Worklog Id: (was: 30173)
Time Spent: 1h (was: 50m)
> Crash when slow logging is enabled.
> ---
>
> Key: TS-4905
> URL: https://issues.apache.org/jira/browse/TS-4905
> Project: Traffic Server
> Issue Type: Bug
>Reporter: James Peach
>Assignee: Masaori Koshiba
>Priority: Blocker
> Fix For: 7.1.0
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> {noformat}
> Thread 14158, [ET_NET 5]:
> 00x004ad342 crash_logger_invoke(int, siginfo_t*, void*) + 0x72
> 10x2abccff59330 __restore_rt + (nil)
> 20x004f166c ProxyClientTransaction::get_netvc() const + 0xc
> 30x005a1712 HttpSM::update_stats() + 0x322
> 40x005b4350 HttpSM::kill_this() + 0x380
> 50x005b4ee8 HttpSM::main_handler(int, void*) + 0x108
> 60x005f174d HttpTunnel::main_handler(int, void*) + 0x19d
> 70x004ea7e2 PluginVC::process_write_side(bool) + 0x572
> 80x004ed1b9 PluginVC::main_handler(int, void*) + 0x3a9
> 90x0076ced0 EThread::process_event(Event*, int) + 0x120
> 10 0x0076db8b EThread::execute() + 0x7fb
> 11 0x0076c95a spawn_thread_internal(void*) + 0x4a
> 12 0x2abccff51184 start_thread + 0xc4
> 13 0x2abcd0c8537d clone + 0x6d
> 14 0x 0x0 + 0x6d
> {noformat}
> In my build (close to master), this happens every time I enable slow logging.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver pull request #1075: TS-4905: Set parent NULL after destroy() i...
Github user shinrich commented on a diff in the pull request:
https://github.com/apache/trafficserver/pull/1075#discussion_r81987102
--- Diff: proxy/http/Http1ClientTransaction.cc ---
@@ -67,6 +67,7 @@ Http1ClientTransaction::transaction_done()
// If the parent session is not in the closed state, the destroy will
not occur.
if (parent) {
parent->destroy();
+parent = NULL;
--- End diff --
Yes, destroy doesn't necessarily destroy. But from transaction_done(), the
client transaction is done with the parent session. So even if the parent is
still around, the client transaction should no longer be manipulating it.
The change looks good to me.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Work logged] (TS-4934) Assert in Http2Stream::do_io_close() when active timeout
[
https://issues.apache.org/jira/browse/TS-4934?focusedWorklogId=30172=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-30172
]
ASF GitHub Bot logged work on TS-4934:
--
Author: ASF GitHub Bot
Created on: 05/Oct/16 14:30
Start Date: 05/Oct/16 14:30
Worklog Time Spent: 10m
Work Description: Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1080
Looks good to me as well. In my working branch I had extended this assert
to
{code}
// Check to see if the stream is in the closed state
ink_assert(get_state() == HTTP2_STREAM_STATE_CLOSED || get_state() ==
HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE);
{code}
But you are exactly right that with timeouts, checking the state is not
particularly useful.
Issue Time Tracking
---
Worklog Id: (was: 30172)
Time Spent: 50m (was: 40m)
> Assert in Http2Stream::do_io_close() when active timeout
>
>
> Key: TS-4934
> URL: https://issues.apache.org/jira/browse/TS-4934
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.1.0
>
> Time Spent: 50m
> Remaining Estimate: 0h
>
> {noformat}
> Program received signal SIGABRT, Aborted.
> 0x726e75f7 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0 0x726e75f7 in raise () from /lib64/libc.so.6
> #1 0x726e8ce8 in abort () from /lib64/libc.so.6
> #2 0x74bf7c4b in ink_abort (message_format=0x74c25700 "%s:%d:
> failed assertion `%s`") at ink_error.cc:79
> #3 0x74bf2bd7 in _ink_assert (expression=0xb43920 "get_state() ==
> HTTP2_STREAM_STATE_CLOSED", file=0xb436a0 "Http2Stream.cc", line=333)
> at ink_assert.cc:37
> #4 0x0075ef92 in Http2Stream::do_io_close (this=0x7fffe6492b40) at
> Http2Stream.cc:333
> #5 0x00679b1d in HttpVCTable::cleanup_entry (this=0x7fffe69c8990,
> e=0x7fffe69c8990) at HttpSM.cc:216
> #6 0x00679bde in HttpVCTable::cleanup_all (this=0x7fffe69c8990) at
> HttpSM.cc:227
> #7 0x006b561f in HttpSM::kill_this (this=0x7fffe69c71e0) at
> HttpSM.cc:6756
> #8 0x0068f792 in HttpSM::main_handler (this=0x7fffe69c71e0,
> event=106, data=0x7fffe6492e88) at HttpSM.cc:2671
> #9 0x00535f6c in Continuation::handleEvent (this=0x7fffe69c71e0,
> event=106, data=0x7fffe6492e88) at ../iocore/eventsystem/I_Continuation.h:153
> #10 0x0075d136 in Http2Stream::main_event_handler
> (this=0x7fffe6492b40, event=106, edata=0x608e00014ce0) at Http2Stream.cc:68
> #11 0x00535f6c in Continuation::handleEvent (this=0x7fffe6492b40,
> event=2, data=0x608e00014ce0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c41 in EThread::process_event (this=0x70c65800,
> e=0x608e00014ce0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a491 in EThread::execute (this=0x70c65800) at
> UnixEThread.cc:225
> #14 0x00a6858c in spawn_thread_internal (a=0x6008000156d0) at
> Thread.cc:84
> #15 0x74e64ac8 in ?? () from /lib64/libasan.so.0
> #16 0x7349ddc5 in start_thread () from /lib64/libpthread.so.0
> #17 0x727a828d in clone () from /lib64/libc.so.6
> (gdb) p get_state()
> $1 = HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver issue #1080: TS-4934: Remove invalid assert
Github user shinrich commented on the issue:
https://github.com/apache/trafficserver/pull/1080
Looks good to me as well. In my working branch I had extended this assert
to
{code}
// Check to see if the stream is in the closed state
ink_assert(get_state() == HTTP2_STREAM_STATE_CLOSED || get_state() ==
HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE);
{code}
But you are exactly right that with timeouts, checking the state is not
particularly useful.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
[jira] [Created] (TS-4936) Add test coverage to CI.
James Peach created TS-4936:
---
Summary: Add test coverage to CI.
Key: TS-4936
URL: https://issues.apache.org/jira/browse/TS-4936
Project: Traffic Server
Issue Type: Test
Reporter: James Peach
Add the {{ci/coverage}} script (or something equivalent) to CI so we can
generate current test code coverage data.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (TS-4916) Http2ConnectionState::restart_streams infinite loop causes deadlock
[
https://issues.apache.org/jira/browse/TS-4916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15548770#comment-15548770
]
Gancho Tenev commented on TS-4916:
--
Looked into this more and here are my findings / hypothesis.
*Studied the list code (lib/ts/List.h)* and found a couple of problems (filed
[TS-4935|https://issues.apache.org/jira/browse/TS-4935])
If the list is used improperly its internal structure gets damaged silently. If
the the same element is added twice in a row the element’s “next” would start
pointing to the element itself and all the pre-existing list content would be
lost. All further additions will be OK but the next list traversal will be
infinite.
*How would we add the same element twice?*
Since a memory pool is used to instantiate the streams it is not impossible to
have exactly the same chunk returned by the pool.
*How could adding the same chunk happen?*
# a stream N is created and used, no new streams are created in the meanwhile
# the stream N is closed and its memory chunk is released back to the pool when
the stream is destroyed.
# fail to remove stream N from the list of active streams (bug!)
# a new stream N+1 is created right after destroying stream N (and getting
exactly the same memory chunk from the memory pool used by stream N)
# add the new stream N+1 to the list of active streams, in this way adding the
same memory chunk to the list for a second time in a row and damaging the
list’s internal structure
# new streams can be added and deleted after this point but the next the active
stream list iteration will be infinite.
*Hypothesis validation*
By the time we identify the infinite loop (which is pretty straight forward)
all the useful info about how we got to this state is gone so in order to
validate this hypothesis I had to collect some more data.
Instrumented the code and added a check for failures to remove the stream from
the list of active streams right before destroying it and in case of failure
removed it (as a “catch all” safety net just before destroying)
It usually took 1-3 days to reach the infinite loop/deadlock after restart.
Run the experimental code for 3+ days without getting into the infinite loop /
deadlock state and the collected data indicates that it would have failed to
remove the stream from the active stream list (which would trigger the infinite
loop state) 4 times during that period. I believe this validates the hypothesis.
*Next steps*
Identified an execution path which could fail to remove the element from the
list before destroying the stream.
Implemented a patch which I just started testing in prod and will provide
update as soon as I validate it.
Please let me know if more info is needed or something does not make sense and
will be happy to look into it!
Cheers,
--Gancho
> Http2ConnectionState::restart_streams infinite loop causes deadlock
>
>
> Key: TS-4916
> URL: https://issues.apache.org/jira/browse/TS-4916
> Project: Traffic Server
> Issue Type: Bug
> Components: Core, HTTP/2
>Reporter: Gancho Tenev
>Assignee: Gancho Tenev
>Priority: Blocker
> Fix For: 7.1.0
>
>
> Http2ConnectionState::restart_streams falls into an infinite loop while
> holding a lock, which leads to cache updates to start failing.
> The infinite loop is caused by traversing a list whose last element “next”
> points to the element itself and the traversal never finishes.
> {code}
> Thread 51 (Thread 0x2aaab3d04700 (LWP 34270)):
> #0 0x2acf3fee in Http2ConnectionState::restart_streams
> (this=0x2ae6ba5284c8) at Http2ConnectionState.cc:913
> #1 rcv_window_update_frame (cstate=..., frame=...) at
> Http2ConnectionState.cc:627
> #2 0x2acf9738 in Http2ConnectionState::main_event_handler
> (this=0x2ae6ba5284c8, event=, edata=) at
> Http2ConnectionState.cc:823
> #3 0x2acef1c3 in Continuation::handleEvent (data=0x2aaab3d039a0,
> event=2253, this=0x2ae6ba5284c8) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #4 send_connection_event (cont=cont@entry=0x2ae6ba5284c8,
> event=event@entry=2253, edata=edata@entry=0x2aaab3d039a0) at
> Http2ClientSession.cc:58
> #5 0x2acef462 in Http2ClientSession::state_complete_frame_read
> (this=0x2ae6ba528290, event=, edata=0x2aab7b237f18) at
> Http2ClientSession.cc:426
> #6 0x2acf0982 in Continuation::handleEvent (data=0x2aab7b237f18,
> event=100, this=0x2ae6ba528290) at
> ../../iocore/eventsystem/I_Continuation.h:153
> #7 Http2ClientSession::state_start_frame_read (this=0x2ae6ba528290,
> event=, edata=0x2aab7b237f18) at Http2ClientSession.cc:399
> #8 0x2acef5a3 in Continuation::handleEvent (data=0x2aab7b237f18,
> event=100, this=0x2ae6ba528290) at
>
[jira] [Commented] (TS-4934) Assert in Http2Stream::do_io_close() when active timeout
[
https://issues.apache.org/jira/browse/TS-4934?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15548792#comment-15548792
]
Leif Hedstrom commented on TS-4934:
---
[~masaori] This doesn't apply to 6.2.x ?
> Assert in Http2Stream::do_io_close() when active timeout
>
>
> Key: TS-4934
> URL: https://issues.apache.org/jira/browse/TS-4934
> Project: Traffic Server
> Issue Type: Bug
> Components: HTTP/2
>Reporter: Masaori Koshiba
>Assignee: Masaori Koshiba
> Fix For: 7.1.0
>
> Time Spent: 40m
> Remaining Estimate: 0h
>
> {noformat}
> Program received signal SIGABRT, Aborted.
> 0x726e75f7 in raise () from /lib64/libc.so.6
> (gdb) bt
> #0 0x726e75f7 in raise () from /lib64/libc.so.6
> #1 0x726e8ce8 in abort () from /lib64/libc.so.6
> #2 0x74bf7c4b in ink_abort (message_format=0x74c25700 "%s:%d:
> failed assertion `%s`") at ink_error.cc:79
> #3 0x74bf2bd7 in _ink_assert (expression=0xb43920 "get_state() ==
> HTTP2_STREAM_STATE_CLOSED", file=0xb436a0 "Http2Stream.cc", line=333)
> at ink_assert.cc:37
> #4 0x0075ef92 in Http2Stream::do_io_close (this=0x7fffe6492b40) at
> Http2Stream.cc:333
> #5 0x00679b1d in HttpVCTable::cleanup_entry (this=0x7fffe69c8990,
> e=0x7fffe69c8990) at HttpSM.cc:216
> #6 0x00679bde in HttpVCTable::cleanup_all (this=0x7fffe69c8990) at
> HttpSM.cc:227
> #7 0x006b561f in HttpSM::kill_this (this=0x7fffe69c71e0) at
> HttpSM.cc:6756
> #8 0x0068f792 in HttpSM::main_handler (this=0x7fffe69c71e0,
> event=106, data=0x7fffe6492e88) at HttpSM.cc:2671
> #9 0x00535f6c in Continuation::handleEvent (this=0x7fffe69c71e0,
> event=106, data=0x7fffe6492e88) at ../iocore/eventsystem/I_Continuation.h:153
> #10 0x0075d136 in Http2Stream::main_event_handler
> (this=0x7fffe6492b40, event=106, edata=0x608e00014ce0) at Http2Stream.cc:68
> #11 0x00535f6c in Continuation::handleEvent (this=0x7fffe6492b40,
> event=2, data=0x608e00014ce0) at ../iocore/eventsystem/I_Continuation.h:153
> #12 0x00a69c41 in EThread::process_event (this=0x70c65800,
> e=0x608e00014ce0, calling_code=2) at UnixEThread.cc:143
> #13 0x00a6a491 in EThread::execute (this=0x70c65800) at
> UnixEThread.cc:225
> #14 0x00a6858c in spawn_thread_internal (a=0x6008000156d0) at
> Thread.cc:84
> #15 0x74e64ac8 in ?? () from /lib64/libasan.so.0
> #16 0x7349ddc5 in start_thread () from /lib64/libpthread.so.0
> #17 0x727a828d in clone () from /lib64/libc.so.6
> (gdb) p get_state()
> $1 = HTTP2_STREAM_STATE_HALF_CLOSED_REMOTE
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (TS-4935) Adding same element twice in a row damages DLL's structure silently
Gancho Tenev created TS-4935: Summary: Adding same element twice in a row damages DLL's structure silently Key: TS-4935 URL: https://issues.apache.org/jira/browse/TS-4935 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Gancho Tenev If the DLL list (lib/ts/List.h) is used improperly its internal structure gets damaged silently without any indication to the caller (no assert or return code). If the the same element is added twice in a row the element's “next” would start pointing to the element itself and all the existing list content would be lost. All further additions will be OK but the next list traversal will be infinite. Also noticed that when a new element is added to the list the element’s “prev” is not initialized (not a problem in the most common case but should to be fixed). -- This message was sent by Atlassian JIRA (v6.3.4#6332)
