[openssl-commits] [openssl] master update

[Matt Caswell]

The branch master has been updated
       via  c796e0215209e68d77dfc23150441a64404a99a5 (commit)
      from  bb9ad09e8ec91d1c3e9c571b4b5ba98980b5fa93 (commit)


- Log -----------------------------------------------------------------
commit c796e0215209e68d77dfc23150441a64404a99a5
Author: Matt Caswell <matt at openssl.org>
Date:   Tue Jun 7 13:24:01 2016 +0100

    Document the issue with threads and dlopen()
    
    If using threads and OpenSSL is loaded via dlopen(), and subsequently
    closed again via dlclose() *before* the threads are destroyed, then
    OpenSSL will not free up the per thread resources. We need to document
    this restriction, and provide some guidance on what to do about it.
    
    I did some testing and discovered/verified a few of things (at least
    this is the behaviour on Linux):
    
    - Using OpenSSL via dlopen in a mutli-threaded app does leak memory if
    threads are destroyed after dlcose() is called.
    - In a single threaded environment, or if threads are destroyed prior to
    dlclose() being called, then no memory is leaked
    - Using the RTLD_NODELETE flag to dlopen solves the above problem
    - Interestingly the OpenSSL atexit() handler gets called when dlclose()
    is called rather than at application exit (I was worred that it might crash
    if there was an atexit() handler for a function that has been unloaded)
    - RTLD_NODELETE is a non-standard flag - but it does seem to be fairly
    widely supported. As far as I could determine (via google), at least Linux,
    Solaris, OpenBSD, FreeBSD, HP-UX all seem to support it.
    
    I also tested on Windows (using LoadLibrary instead of dlopen and
    FreeLibrary instead of dlclose) and experienced similar behaviour, except
    that (AFAIK) there is no equivalent of RTLD_NODELETE on Windows.
    
    GitHub Issue #653
    
    Reviewed-by: Richard Levitte <levitte at openssl.org>

-----------------------------------------------------------------------

Summary of changes:
 doc/crypto/OPENSSL_init_crypto.pod | 16 +++++++++++++---
 1 file changed, 13 insertions(+), 3 deletions(-)

diff --git a/doc/crypto/OPENSSL_init_crypto.pod b/doc/crypto/OPENSSL_init_crypto.pod
index 8caa361..a35325b 100644
--- a/doc/crypto/OPENSSL_init_crypto.pod
+++ b/doc/crypto/OPENSSL_init_crypto.pod
@@ -203,9 +203,19 @@ platforms this is done in response to a DLL_THREAD_DETACH message being sent to
 the libcrypto32.dll entry point. Some windows functions may cause threads to exit
 without sending this message (for example ExitProcess()). If the application
 uses such functions, then the application must free up OpenSSL resources
-directly via a call to OPENSSL_thread_stop(). Similarly this message will
-also not be sent if OpenSSL is linked statically, and therefore applications
-using static linking should also call OPENSSL_thread_stop().
+directly via a call to OPENSSL_thread_stop() on each thread. Similarly this
+message will also not be sent if OpenSSL is linked statically, and therefore
+applications using static linking should also call OPENSSL_thread_stop() on each
+thread. Additionally if OpenSSL is loaded dynamically via LoadLibrary() and the
+threads are not destroyed until after FreeLibrary() is called then each thread
+should call OPENSSL_thread_stop() prior to the FreeLibrary() call.
+
+On Linux/Unix where OpenSSL has been loaded via dlopen() and the application is
+multi-threaded and if dlclose() is subsequently called prior to the threads
+being destroyed then OpenSSL will not be able to deallocate resources associated
+with those threads. The application should either call OPENSSL_thread_stop() on
+each thread prior to the dlclose() call, or alternatively the original dlopen()
+call should use the RTLD_NODELETE flag (where available on the platform).
 
 =head1 RETURN VALUES