Bug 1707227
Summary: | glusterfsd memory leak after enable tls/ssl | |||
---|---|---|---|---|
Product: | [Community] GlusterFS | Reporter: | zhou lin <zz.sh.cynthia> | |
Component: | rpc | Assignee: | bugs <bugs> | |
Status: | CLOSED DUPLICATE | QA Contact: | ||
Severity: | high | Docs Contact: | ||
Priority: | high | |||
Version: | 4.1 | CC: | bugs, jahernan | |
Target Milestone: | --- | |||
Target Release: | --- | |||
Hardware: | x86_64 | |||
OS: | Linux | |||
Whiteboard: | ||||
Fixed In Version: | Doc Type: | If docs needed, set a value | ||
Doc Text: | Story Points: | --- | ||
Clone Of: | ||||
: | 1708047 (view as bug list) | Environment: | ||
Last Closed: | 2020-01-27 10:53:52 UTC | Type: | Bug | |
Regression: | --- | Mount Type: | --- | |
Documentation: | --- | CRM: | ||
Verified Versions: | Category: | --- | ||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
Cloudforms Team: | --- | Target Upstream Version: | ||
Embargoed: | ||||
Bug Depends On: | ||||
Bug Blocks: | 1708047 |
Description
zhou lin
2019-05-07 05:56:57 UTC
thanks for your respond! glusterfsd process does call SSL_free interface, however, the ssl context is a shared one between many ssl object. do you think it is possible that if we keep the shared ssl context will cause this memory leak? REVIEW: https://review.gluster.org/22687 (After enabling TLS, glusterfsd memory leak found) posted (#1) for review on master by None REVISION POSTED: https://review.gluster.org/22687 (rpc/socket: After enabling TLS, glusterfsd memory leak found) posted (#2) for review on master by Raghavendra G Zhou Lin, is the issue fixed? I see that this patch is Abandon'd by you. Feel free to close it if this is working for you in later releases/branches. unfortunately , the version i use is already different from the master branch , the ssl_ctx is shared one in my version and in master branch each connection has seperate ssl_ctx, so the method i use to fix the memory leak does not apply to the master branch although my test shows even in master branch this memory leak also exists. the patch i use in my version can fix the memory leak issue: --- a/rpc/rpc-transport/socket/src/socket.c +++ b/rpc/rpc-transport/socket/src/socket.c @@ -367,6 +367,7 @@ static char *ssl_setup_connection_postfix(rpc_transport_t *this) { gf_log(this->name, GF_LOG_DEBUG, "SSL verification succeeded (client: %s) (server: %s)", this->peerinfo.identifier, this->myinfo.identifier); + X509_free(peer); return gf_strdup(peer_CN); /* Error paths. */ @@ -1019,7 +1020,16 @@ static void __socket_reset(rpc_transport_t *this) { memset(&priv->incoming, 0, sizeof(priv->incoming)); event_unregister_close(this->ctx->event_pool, priv->sock, priv->idx); - + if(priv->use_ssl&& priv->ssl_ssl) + { + gf_log(this->name, GF_LOG_INFO, + "clear and reset for socket(%d), free ssl ", + priv->sock); + // SSL_shutdown(priv->ssl_ssl); + SSL_clear(priv->ssl_ssl); + SSL_free(priv->ssl_ssl); + priv->ssl_ssl = NULL; + } priv->sock = -1; priv->idx = -1; priv->connected = -1; @@ -4238,6 +4248,16 @@ void fini(rpc_transport_t *this) { pthread_mutex_destroy(&priv->out_lock); pthread_mutex_destroy(&priv->cond_lock); pthread_cond_destroy(&priv->cond); + if(priv->use_ssl&& priv->ssl_ssl) + { + gf_log(this->name, GF_LOG_TRACE, + "clear and reset for socket(%d), free ssl ", + priv->sock); + // SSL_shutdown(priv->ssl_ssl); + SSL_clear(priv->ssl_ssl); + SSL_free(priv->ssl_ssl); + priv->ssl_ssl = NULL; + } if (priv->ssl_private_key) { GF_FREE(priv->ssl_private_key); } This is a duplicate of 1768339 *** This bug has been marked as a duplicate of bug 1768339 *** |