On 06/01/17 14:36, Dan Heinz wrote: >>> On 04/01/17 23:11, Dan Heinz wrote: Using openssl 1.1.0c. >>> >>> I have a test application that is a win32 console app that calls >>> a win32 DLL which has the openssl libraries linked in >>> statically. >>> >>> The test applications uses late-binding to the DLL and calls >>> LoadLibrary for the DLL, one test function in the DLL, and then >>> FreeLibrary on the DLL. >>> >>> >>> >>> The test function in the DLL does the following: >>> >>> RSA*rsa = NULL; >>> >>> rsa = RSA_new(); >>> >>> RSA_free(rsa); >>> >>> OPENSSL_thread_stop(); >>> >>> OPENSSL_cleanup(); >>> >>> return0; >>> >>> When FreeLibrary is called on the DLL, dllmain in never called >>> with any messages. A subsequent call to LoadLibrary also fails >>> to call dllmain and when the test function is called RSA_new() >>> fails. This leads me to believe the DLL is never freed. >>> >>> I have tried building openssl with and without no-threads with >>> the same results. My build parameters are: perl Configure >>> *%TEMP_ARCHITECTURE%* >>> --prefix=*%RootPath_ThirdParty%*\*%OPENSSL_VERSION%* -DPURIFY >>> -DOPENSSL_NO_COMP -D_USING_V110_SDK71_ no-shared no-threads >>> no-asm no-idea no-mdc2 no-rc5 no-ssl3 no-zlib no-comp >>> >>> What am I missing? >> >> >> OpenSSL does its cleanup at *process* exit. Don't call >> OPENSSL_cleanup() explicitly - this is >discouraged. >> >> From this manpage: >> >> https://www.openssl.org/docs/man1.1.0/crypto/OPENSSL_init_crypto.html >> >> >> "Typically there should be no need to call this function directly as it is initiated >automatically on application exit...<snip>... >> >> Once OPENSSL_cleanup() has been called the library cannot be >> reinitialised." >> >> This last sentence is the reason why RSA_new() will fail after you >> have previously called >OPENSSL_cleanup(). >> >> Because cleanup happens on process exit, OpenSSL will keep itself >> in memory until that time >(otherwise crashes will occur because >> the cleanup routines have been unloaded). >> >> If you want to dynamically load and unload your DLL then don't >> statically link it to OpenSSL - >otherwise OpenSSL will keep your >> DLL around until process exit too. >> >> Matt > > That is very disappointing. As a library vendor we have no control > over how our users load and unload our libraries. We will just have > to roll back to 1.0.x and wait to see if this will be addressed. > Also, as Jakob stated in another post, it really seems like this > design will be problematic. Can you not link against the OpenSSL DLLs rather than statically link? That would avoid the problem. Matt -- openssl-users mailing list To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users