thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James E. King, III (JIRA)" <>
Subject [jira] [Commented] (THRIFT-4164) Core in TSSLSocket cleanupOpenSSL when destroying a mutex used by openssl
Date Mon, 03 Apr 2017 21:40:41 GMT


James E. King, III commented on THRIFT-4164:

PR #1235 exposed the fact that before that PR, we were quietly stopping openssl from using
the locking callbacks we were providing.  This would lead to unsafe multi-thread behavior
during shutdown.  

I looked at guaranteeing this in core: I noodled through it and the solutions were all a bit
ugly, involving the factory to keep a smart pointer of each socket it made, and a callback
from TSSLSocket::close() to the factory to take it out of a set of sockets it had made.  Then
in ~TSSLSocketFactory we would need to guarantee the set of sockets left in the factory were
the last instance (nobody else was holding onto them as well) so we could guarantee that when
the set of sockets is reset, all the sockets the factory ever made were released.Then the
factory could clean up openssl safely.

OR, we clearly document the requirement that a factory must outlive any sockets it makes.
 This is what I'm going to do, so will revise the PR to fix our own TestClient.cpp which was
in violation of the requirement that a TSSLSocketFactory must outlive any TSSLSocket it creates
when the TSSLSocketFactory is managing openssl initialization and destruction, which was causing
the build failures.

> Core in TSSLSocket cleanupOpenSSL when destroying a mutex used by openssl
> -------------------------------------------------------------------------
>                 Key: THRIFT-4164
>                 URL:
>             Project: Thrift
>          Issue Type: Bug
>          Components: C++ - Library
>    Affects Versions: 0.10.0
>         Environment: Ubuntu 14.04, openssl (version TBD, I believe it is a 1.1.0 variant)
>            Reporter: James E. King, III
>            Assignee: James E. King, III
> In a project where thrift is used, i was investigating a core in an assertion in apache::thrift::concurrency::~Mutex
(pthread variety).  The mutex in question was one of the locking mutexes that thrift gives
to openssl.  The core occurred in TSSLSocket::cleanupOpenSSL() where the mutexes are destroyed
(on the last line).
> I suspect that we might be changing the locking callbacks too early in the cleanup process;
perhaps one of the other cleanup calls that follows it would have released a mutex in some
situations?  In any case, this needs to be investigated and I am assigning it to myself.

This message was sent by Atlassian JIRA

View raw message