[
https://issues.apache.org/jira/browse/THRIFT-4164?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15954194#comment-15954194
]
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: https://issues.apache.org/jira/browse/THRIFT-4164
> 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
(v6.3.15#6346)
