mirror of
https://github.com/curl/curl.git
synced 2026-08-03 00:20:36 +03:00
dllmain: Call OpenSSL thread cleanup for Windows and Cygwin
- Call OPENSSL_thread_stop on thread termination (DLL_THREAD_DETACH) to prevent a memory leak in case OpenSSL is linked statically. - Warn in libcurl-thread.3 that if OpenSSL is linked statically then it may require thread cleanup. OpenSSL may need per-thread cleanup to stop a memory leak. For Windows and Cygwin if libcurl was built as a DLL then we can do that for the user by calling OPENSSL_thread_stop on thread termination. However, if libcurl was built statically then we do not have notification of thread termination and cannot do that for the user. Also, there are several other unusual cases where it may be necessary for the user to call OPENSSL_thread_stop, so in the libcurl-thread warning I added a link to the OpenSSL documentation. Co-authored-by: Viktor Szakats Reported-by: southernedge@users.noreply.github.com Reported-by: zmcx16@users.noreply.github.com Ref: https://www.openssl.org/docs/man3.0/man3/OPENSSL_thread_stop.html#NOTES Fixes https://github.com/curl/curl/issues/12327 Closes https://github.com/curl/curl/pull/12408
This commit is contained in:
parent
3b8db84c1b
commit
7860f575fe
5 changed files with 134 additions and 15 deletions
|
|
@ -54,6 +54,11 @@ still running then your program may crash or other corruption may occur. We
|
|||
recommend you do not run libcurl from any module that may be unloaded
|
||||
dynamically. This behavior may be addressed in the future.
|
||||
|
||||
libcurl may not be able to fully clean up after multi-threaded OpenSSL
|
||||
depending on how OpenSSL was built and loaded as a library. It is possible in
|
||||
some rare circumstances a memory leak could occur unless you implement your own
|
||||
OpenSSL thread cleanup. Refer to libcurl-thread(3).
|
||||
|
||||
# EXAMPLE
|
||||
|
||||
~~~c
|
||||
|
|
|
|||
|
|
@ -37,10 +37,28 @@ share API (the connection pool and HSTS cache for example).
|
|||
|
||||
# TLS
|
||||
|
||||
All current TLS libraries libcurl supports are thread-safe. OpenSSL 1.1.0+ can
|
||||
be safely used in multi-threaded applications provided that support for the
|
||||
underlying OS threading API is built-in. For older versions of OpenSSL, the
|
||||
user must set mutex callbacks.
|
||||
All current TLS libraries libcurl supports are thread-safe.
|
||||
|
||||
## OpenSSL
|
||||
|
||||
OpenSSL 1.1.0+ can be safely used in multi-threaded applications provided that
|
||||
support for the underlying OS threading API is built-in. For older versions of
|
||||
OpenSSL, the user must set mutex callbacks.
|
||||
|
||||
libcurl may not be able to fully clean up after multi-threaded OpenSSL
|
||||
depending on how OpenSSL was built and loaded as a library. It is possible in
|
||||
some rare circumstances a memory leak could occur unless you implement your own
|
||||
OpenSSL thread cleanup.
|
||||
|
||||
For example, on Windows if both libcurl and OpenSSL are linked statically to a
|
||||
DLL or application then OpenSSL may leak memory unless the DLL or application
|
||||
calls OPENSSL_thread_stop() before each thread terminates. If OpenSSL is built
|
||||
as a DLL then it does this cleanup automatically and there is no leak. If
|
||||
libcurl is built as a DLL and OpenSSL is linked statically to it then libcurl
|
||||
does this cleanup automatically and there is no leak (added in libcurl 8.8.0).
|
||||
|
||||
Please review the OpenSSL documentation for a full list of circumstances:
|
||||
https://www.openssl.org/docs/man3.0/man3/OPENSSL_thread_stop.html#NOTES
|
||||
|
||||
# Signals
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue