-
由 Matt Caswell 提交于
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: NRichard Levitte <levitte@openssl.org>
c796e021