[jira] [Created] (TS-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()
Oknet Xu created TS-4879: Summary: NetVC leaks while hyper emergency occur on check_emergency_throttle() Key: TS-4879 URL: https://issues.apache.org/jira/browse/TS-4879 Project: Traffic Server Issue Type: Bug Components: Core Reporter: Oknet Xu The con could be closed if hyper emergency occur on check_emergency_throttle(). But we did not check the con.fd while we get return from check_emergency_throttle(). For hyper emergency: - The socket fd is removed from epoll while it is closed. - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to SM. Thus: - The NetVC will never triggered by NetHandler. - Only InactivityCop could handle the NetVC and the default timeout value is 86400 secs. For the counter: net_connections_currently_open_stat - It is increased in “connect_re_internal()” - It isn't decreased while the con.fd set to NO_FD due to hyper emergency - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Assigned] (TS-4879) NetVC leaks while hyper emergency occur on check_emergency_throttle()
[ https://issues.apache.org/jira/browse/TS-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Oknet Xu reassigned TS-4879: Assignee: Oknet Xu > NetVC leaks while hyper emergency occur on check_emergency_throttle() > - > > Key: TS-4879 > URL: https://issues.apache.org/jira/browse/TS-4879 > Project: Traffic Server > Issue Type: Bug > Components: Core >Reporter: Oknet Xu >Assignee: Oknet Xu > > The con could be closed if hyper emergency occur on > check_emergency_throttle(). > But we did not check the con.fd while we get return from > check_emergency_throttle(). > For hyper emergency: > - The socket fd is removed from epoll while it is closed. > - A NetVC with a closed socket fd is created and callback NET_EVENT_OPEN to > SM. > Thus: > - The NetVC will never triggered by NetHandler. > - Only InactivityCop could handle the NetVC and the default timeout value is > 86400 secs. > For the counter: net_connections_currently_open_stat > - It is increased in “connect_re_internal()” > - It isn't decreased while the con.fd set to NO_FD due to hyper emergency > - Because it is decreased in close_UnixNetVConnection() only con.fd != NO_FD. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (TS-4817) Frequent segfaults in Cache::open_write
[
https://issues.apache.org/jira/browse/TS-4817?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501591#comment-15501591
]
Mathias Biilmann Christensen commented on TS-4817:
--
True, though it always seems to occur during the Cache::open_write in the core
dumps I've collected...
> Frequent segfaults in Cache::open_write
> ---
>
> Key: TS-4817
> URL: https://issues.apache.org/jira/browse/TS-4817
> Project: Traffic Server
> Issue Type: Bug
> Components: Cache, HTTP
>Reporter: Mathias Biilmann Christensen
> Fix For: 7.1.0
>
> Attachments: core-dump.tar.gz
>
>
> I've been running some tests with the master branch sending some production
> traffic to a test server, and am seeing very frequent segfaults.
> I'm running fb8bcbcac3c1d6c7a15340f0093342fb9f207e78
> The stack traces look like this:
> {noformat}
> traffic_server - STACK TRACE:
> /opt/ts/bin/traffic_server(crash_logger_invoke(int, siginfo_t*,
> void*)+0xc3)[0x511280]
> /lib/x86_64-linux-gnu/libpthread.so.0(+0x10330)[0x2ae12de39330]
> /lib/x86_64-linux-gnu/libc.so.6(gsignal+0x37)[0x2ae12eaa1c37]
> /lib/x86_64-linux-gnu/libc.so.6(abort+0x148)[0x2ae12eaa5028]
> /opt/ts/lib/libtsutil.so.7(ink_warning(char const*, ...)+0x0)[0x2ae12cb11f4e]
> /opt/ts/lib/libtsutil.so.7(ats_base64_encode(unsigned char const*, unsigned
> long, char*, unsigned long, unsigned long*)+0x0)[0x2ae12cb0f8e4]
> /opt/ts/bin/traffic_server(HttpTunnel::consumer_handler(int,
> HttpTunnelConsumer*)+0xcc)[0x63efb2]
> /opt/ts/bin/traffic_server(HttpTunnel::main_handler(int,
> void*)+0x133)[0x63f9b7]
> /opt/ts/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x72)[0x51425a]
> /opt/ts/bin/traffic_server(CacheVC::calluser(int)+0xaa)[0x74f4c8]
> /opt/ts/bin/traffic_server(CacheVC::openWriteMain(int,
> Event*)+0x3de)[0x759d48]
> /opt/ts/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x72)[0x51425a]
> /opt/ts/bin/traffic_server(CacheVC::callcont(int)+0xfc)[0x74f608]
> /opt/ts/bin/traffic_server(CacheVC::openWriteStartDone(int,
> Event*)+0x8a4)[0x75a9ee]
> /opt/ts/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x72)[0x51425a]
> /opt/ts/bin/traffic_server(CacheVC::handleReadDone(int,
> Event*)+0xd15)[0x72a3e7]
> /opt/ts/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x72)[0x51425a]
> /opt/ts/bin/traffic_server(Cache::open_write(Continuation*, ats::CryptoHash
> const*, HTTPInfo*, long, ats::CryptoHash const*, CacheFragType, char const*,
> int)+0x6f$
> )[0x75b9df]
> /opt/ts/bin/traffic_server(CacheProcessor::open_write(Continuation*, int,
> HttpCacheKey const*, bool, HTTPHdr*, HTTPInfo*, long,
> CacheFragType)+0x129)[0x72eee5]
> /opt/ts/bin/traffic_server(HttpCacheSM::open_write(HttpCacheKey const*, URL*,
> HTTPHdr*, HTTPInfo*, long, bool, bool)+0x236)[0x5d25a2]
> /opt/ts/bin/traffic_server(HttpSM::do_cache_prepare_action(HttpCacheSM*,
> HTTPInfo*, bool, bool)+0x352)[0x5f054e]
> /opt/ts/bin/traffic_server(HttpSM::do_cache_prepare_write_transform()+0x69)[0x6013dd]
> /opt/ts/bin/traffic_server(HttpSM::set_next_state()+0x1a27)[0x5fb613]
> /opt/ts/bin/traffic_server(HttpSM::call_transact_and_set_next_state(void
> (*)(HttpTransact::State*))+0x1ae)[0x5f9be4]
> /opt/ts/bin/traffic_server(HttpSM::state_response_wait_for_transform_read(int,
> void*)+0x19b)[0x5e35cd]
> /opt/ts/bin/traffic_server(HttpSM::main_handler(int, void*)+0x33a)[0x5e88ac]
> /opt/ts/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x72)[0x51425a]
> /opt/ts/bin/traffic_server(TransformTerminus::handle_event(int,
> void*)+0x2fe)[0x561096]
> /opt/ts/bin/traffic_server(Continuation::handleEvent(int,
> void*)+0x72)[0x51425a]
> /opt/ts/bin/traffic_server(EThread::process_event(Event*,
> int)+0x136)[0x7b3eac]
> /opt/ts/bin/traffic_server(EThread::execute()+0xdc)[0x7b410c]
> /opt/ts/bin/traffic_server(main+0x139c)[0x546c99]
> /lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5)[0x2ae12ea8cf45]
> /opt/ts/bin/traffic_server[0x4f9840]
> FATAL: HttpTunnel.cc:1372: failed assertion `c->alive == true`
> {noformat}
> I'm attaching a core dump from a debug build of ATS as well
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[GitHub] trafficserver issue #1029: Add a stub CONTRIBUTING file.
Github user jpeach commented on the issue: https://github.com/apache/trafficserver/pull/1029 If everyone is done testing the review features, I'll merge this tomorrow. --- 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-803) Fix SOCKS breakage and allow for setting next-hop SOCKS
[
https://issues.apache.org/jira/browse/TS-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15501506#comment-15501506
]
James Peach commented on TS-803:
Yep, we should take it through [API
review|https://cwiki.apache.org/confluence/display/TS/API+Review+Process].
Looking at the patch above, I'd recommend we call it something line
{{TSHttpTxnSocksParentAddrSet}} since {{AddrSet}} is the naming convention we
have for setting addresses. It should take a {{const struct sockaddr*}}.
> Fix SOCKS breakage and allow for setting next-hop SOCKS
> ---
>
> Key: TS-803
> URL: https://issues.apache.org/jira/browse/TS-803
> Project: Traffic Server
> Issue Type: New Feature
> Components: Network, SOCKS
>Affects Versions: 3.0.0
> Environment: Wherever ATS might run
>Reporter: M. Nunberg
>
> Here is a patch I drew up a few months ago against a snapshot of ATS/2.1.7
> unstable/git. There are some quirks here, and I'm not that sure any more what
> this patch does exactly. However it:
> 1) Does fix SOCKS connections in general
> 2) Allows setting next-hop SOCKS proxy via the API
> Problems:
> See https://issues.apache.org/jira/browse/TS-802
> This has no effect on connections which are drawn from the connection pool,
> as it seems ATS currently doesn't maintain unique identities for peripheral
> connection params (source IP, SOCKS etc); i.e. this only affects new TCP
> connections to an OS.
> diff -x '*.o' -ru tsorig/iocore/net/I_NetVConnection.h
> tsgit217/iocore/net/I_NetVConnection.h
> --- tsorig/iocore/net/I_NetVConnection.h2011-03-09 21:43:58.0
> +
> +++ tsgit217/iocore/net/I_NetVConnection.h2011-03-17 14:37:18.0
> +
> @@ -120,6 +120,13 @@
>/// Version of SOCKS to use.
>unsigned char socks_version;
> + struct {
> + unsigned int ip;
> + int port;
> + char *username;
> + char *password;
> + } socks_override;
> +
>int socket_recv_bufsize;
>int socket_send_bufsize;
> Only in tsgit217/iocore/net: Makefile
> Only in tsgit217/iocore/net: Makefile.in
> diff -x '*.o' -ru tsorig/iocore/net/P_Socks.h tsgit217/iocore/net/P_Socks.h
> --- tsorig/iocore/net/P_Socks.h2011-03-09 21:43:58.0 +
> +++ tsgit217/iocore/net/P_Socks.h2011-03-17 13:17:20.0 +
> @@ -126,7 +126,7 @@
>unsigned char version;
>bool write_done;
> -
> + bool manual_parent_selection;
>SocksAuthHandler auth_handler;
>unsigned char socks_cmd;
> @@ -145,7 +145,8 @@
> SocksEntry():Continuation(NULL), netVConnection(0),
> ip(0), port(0), server_ip(0), server_port(0), nattempts(0),
> -lerrno(0), timeout(0), version(5), write_done(false),
> auth_handler(NULL), socks_cmd(NORMAL_SOCKS)
> +lerrno(0), timeout(0), version(5), write_done(false),
> manual_parent_selection(false),
> +auth_handler(NULL), socks_cmd(NORMAL_SOCKS)
>{
>}
> };
> diff -x '*.o' -ru tsorig/iocore/net/Socks.cc tsgit217/iocore/net/Socks.cc
> --- tsorig/iocore/net/Socks.cc2011-03-09 21:43:58.0 +
> +++ tsgit217/iocore/net/Socks.cc2011-03-17 13:46:07.0 +
> @@ -73,7 +73,8 @@
>nattempts = 0;
>findServer();
> - timeout = this_ethread()->schedule_in(this,
> HRTIME_SECONDS(netProcessor.socks_conf_stuff->server_connect_timeout));
> +// timeout = this_ethread()->schedule_in(this,
> HRTIME_SECONDS(netProcessor.socks_conf_stuff->server_connect_timeout));
> + timeout = this_ethread()->schedule_in(this, HRTIME_SECONDS(5));
>write_done = false;
> }
> @@ -81,6 +82,15 @@
> SocksEntry::findServer()
> {
>nattempts++;
> + if(manual_parent_selection) {
> + if(nattempts > 1) {
> + //Nullify IP and PORT
> + server_ip = -1;
> + server_port = 0;
> + }
> + Debug("mndebug(Socks)", "findServer() is a noop with manual socks
> selection");
> + return;
> + }
> #ifdef SOCKS_WITH_TS
>if (nattempts == 1) {
> @@ -187,7 +197,6 @@
> }
> Debug("Socks", "Failed to connect to %u.%u.%u.%u:%d",
> PRINT_IP(server_ip), server_port);
> -
> findServer();
> if (server_ip == (uint32_t) - 1) {
> diff -x '*.o' -ru tsorig/iocore/net/UnixNetProcessor.cc
> tsgit217/iocore/net/UnixNetProcessor.cc
> --- tsorig/iocore/net/UnixNetProcessor.cc2011-03-09 21:43:58.0
> +
> +++ tsgit217/iocore/net/UnixNetProcessor.cc2011-03-17 15:48:38.0
> +
> @@ -228,6 +228,11 @@
>!socks_conf_stuff->ip_range.match(ip))
> #endif
> );
> + if(opt->socks_override.ip >= 1) {
> + using_socks = true;
> + Debug("mndebug", "trying to set using_socks to true");
> + }
> +
>SocksEntry *socksEntry = NULL;
> #endif
>NET_SUM_GLOBAL_DYN_STAT(net_connections_currently_open_stat, 1);
> @@ -242,6 +247,16 @@
>if
[jira] [Commented] (TS-803) Fix SOCKS breakage and allow for setting next-hop SOCKS
[
https://issues.apache.org/jira/browse/TS-803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15500410#comment-15500410
]
Oknet Xu commented on TS-803:
-
[~jpe...@apache.org] The patch implemented a new API: TSHttpTxnSocksProxySet to
set socks server in plugin manually. And I don't find any codes related to
“Does fix SOCKS connections in general”.
Does it need API REVIEW if it is a new API ?
> Fix SOCKS breakage and allow for setting next-hop SOCKS
> ---
>
> Key: TS-803
> URL: https://issues.apache.org/jira/browse/TS-803
> Project: Traffic Server
> Issue Type: New Feature
> Components: Network, SOCKS
>Affects Versions: 3.0.0
> Environment: Wherever ATS might run
>Reporter: M. Nunberg
>
> Here is a patch I drew up a few months ago against a snapshot of ATS/2.1.7
> unstable/git. There are some quirks here, and I'm not that sure any more what
> this patch does exactly. However it:
> 1) Does fix SOCKS connections in general
> 2) Allows setting next-hop SOCKS proxy via the API
> Problems:
> See https://issues.apache.org/jira/browse/TS-802
> This has no effect on connections which are drawn from the connection pool,
> as it seems ATS currently doesn't maintain unique identities for peripheral
> connection params (source IP, SOCKS etc); i.e. this only affects new TCP
> connections to an OS.
> diff -x '*.o' -ru tsorig/iocore/net/I_NetVConnection.h
> tsgit217/iocore/net/I_NetVConnection.h
> --- tsorig/iocore/net/I_NetVConnection.h2011-03-09 21:43:58.0
> +
> +++ tsgit217/iocore/net/I_NetVConnection.h2011-03-17 14:37:18.0
> +
> @@ -120,6 +120,13 @@
>/// Version of SOCKS to use.
>unsigned char socks_version;
> + struct {
> + unsigned int ip;
> + int port;
> + char *username;
> + char *password;
> + } socks_override;
> +
>int socket_recv_bufsize;
>int socket_send_bufsize;
> Only in tsgit217/iocore/net: Makefile
> Only in tsgit217/iocore/net: Makefile.in
> diff -x '*.o' -ru tsorig/iocore/net/P_Socks.h tsgit217/iocore/net/P_Socks.h
> --- tsorig/iocore/net/P_Socks.h2011-03-09 21:43:58.0 +
> +++ tsgit217/iocore/net/P_Socks.h2011-03-17 13:17:20.0 +
> @@ -126,7 +126,7 @@
>unsigned char version;
>bool write_done;
> -
> + bool manual_parent_selection;
>SocksAuthHandler auth_handler;
>unsigned char socks_cmd;
> @@ -145,7 +145,8 @@
> SocksEntry():Continuation(NULL), netVConnection(0),
> ip(0), port(0), server_ip(0), server_port(0), nattempts(0),
> -lerrno(0), timeout(0), version(5), write_done(false),
> auth_handler(NULL), socks_cmd(NORMAL_SOCKS)
> +lerrno(0), timeout(0), version(5), write_done(false),
> manual_parent_selection(false),
> +auth_handler(NULL), socks_cmd(NORMAL_SOCKS)
>{
>}
> };
> diff -x '*.o' -ru tsorig/iocore/net/Socks.cc tsgit217/iocore/net/Socks.cc
> --- tsorig/iocore/net/Socks.cc2011-03-09 21:43:58.0 +
> +++ tsgit217/iocore/net/Socks.cc2011-03-17 13:46:07.0 +
> @@ -73,7 +73,8 @@
>nattempts = 0;
>findServer();
> - timeout = this_ethread()->schedule_in(this,
> HRTIME_SECONDS(netProcessor.socks_conf_stuff->server_connect_timeout));
> +// timeout = this_ethread()->schedule_in(this,
> HRTIME_SECONDS(netProcessor.socks_conf_stuff->server_connect_timeout));
> + timeout = this_ethread()->schedule_in(this, HRTIME_SECONDS(5));
>write_done = false;
> }
> @@ -81,6 +82,15 @@
> SocksEntry::findServer()
> {
>nattempts++;
> + if(manual_parent_selection) {
> + if(nattempts > 1) {
> + //Nullify IP and PORT
> + server_ip = -1;
> + server_port = 0;
> + }
> + Debug("mndebug(Socks)", "findServer() is a noop with manual socks
> selection");
> + return;
> + }
> #ifdef SOCKS_WITH_TS
>if (nattempts == 1) {
> @@ -187,7 +197,6 @@
> }
> Debug("Socks", "Failed to connect to %u.%u.%u.%u:%d",
> PRINT_IP(server_ip), server_port);
> -
> findServer();
> if (server_ip == (uint32_t) - 1) {
> diff -x '*.o' -ru tsorig/iocore/net/UnixNetProcessor.cc
> tsgit217/iocore/net/UnixNetProcessor.cc
> --- tsorig/iocore/net/UnixNetProcessor.cc2011-03-09 21:43:58.0
> +
> +++ tsgit217/iocore/net/UnixNetProcessor.cc2011-03-17 15:48:38.0
> +
> @@ -228,6 +228,11 @@
>!socks_conf_stuff->ip_range.match(ip))
> #endif
> );
> + if(opt->socks_override.ip >= 1) {
> + using_socks = true;
> + Debug("mndebug", "trying to set using_socks to true");
> + }
> +
>SocksEntry *socksEntry = NULL;
> #endif
>NET_SUM_GLOBAL_DYN_STAT(net_connections_currently_open_stat, 1);
> @@ -242,6 +247,16 @@
>if (using_socks) {
> Debug("Socks", "Using Socks ip: %u.%u.%u.%u:%d\n", PRINT_IP(ip), port);
>
