OpenSSL memory leak without call to SSL_COMP_free_compression_methods #817
Comments
|
So when built and used normally there is no leak. You rebuild OpenSSL and run it again and now it leaks. Isn't that an OpenSSL problem? Isn't that an ABI break that it doesn't behave the same way? |
|
By default, OPENSSL_NO_COMP is not defined. At least, when using nt.mak and ntdll.mak Edit: The only thing I've changed in the default VC++ build process is the runtime library |
|
Oh, are you saying you have a memory leak with a default build of OpenSSL? I don't, on Linux at least. |
|
That's correct. Sorry for the confusion. I included OPENSSL_NO_COMP in the title because is directly related to the problem. Sensibly, it should be defined in the default build process, but I avoid modifying that build process as much as possible. To give you some details on what is happening. I am wrapping cURL in a COM library (staticly linked to cURL and OpenSSL) that can be loaded/unloaded as needed. I'm not entirely sure how COM isolates the memory, but I know that every time the library loads it allocates new memory within the process. That's why we can't just load Anyway, during a stress test, I found that the library was leaking an 36 bytes every time it was loaded/unloaded which added up after a few hours. That lead to the code sample in the original post. |
|
Confirmed with Windows 7 x64 Enterprise w/curl from master (53ae370 2016-05-20) and OpenSSL/1.0.2h default config. I guess it is documented somewhere in openssl that we're supposed to call that function on cleanup? This is the first time I've heard of it.
Initializing libcurl from a DLL is tricky. |
|
It's a horrible mess. The Docs added over a year later in 2015: openssl/openssl@c490a5512e98 In April 2016, the function is marked deprecated and a no-op: openssl/openssl@03b0e735556ed (I assume this is the 1.1.0 branch) So, there's a version gap in there during which it can/should be used... |
I'm still doing testing on it and it won't be something that I'll push into production lightly. The whole reason this came up is that OpenSSL is already loaded in memory. The library wasn't able to reference that shared memory. cURL always reported SSL errors. I switched to using
Agreed. Plus, the updated documentation for 1.1.0 states that everything will be handled automagically, but given my predicament, I'll have to force cleanup one way or another.
https://www.openssl.org/docs/manmaster/ssl/OPENSSL_init_ssl.html Given the state of things, you should probably change this to a "will not fix". I just want there to be a clear record of it, one way or another. |
bagder
changed the title
- Free compression methods if OpenSSL 1.0.2 to avoid a memory leak. Bug: #817 Reported-by: jveazey@users.noreply.github.com
If you have a static OpenSSL library in your DLL you should be OK as long as you control the code and know what is going on. The problems come in when there are OpenSSL DLLs (or shared objects in the case of Linux) that are used by the application or another library loaded by the application (ie not your library) and do their own openssl initialization or thread hook routines (usurping yours). In some cases if it's proven that it's guaranteed to be already initialized properly by other means I've advised to not call with global_all (in other words do
We support and will continue to support 1.0.2 so I've put in a fix. Thanks, landed in 3caaeff. |
|
This change is causing segfault of php when curl module is loaded. Reverting commit 3caaeff and problem is gone. Tested on php5.3.29 and 5.5.36. openssl 1.0.2h |
…sl users; will see how upstream will solve this (curl/curl#817)
|
@arekm Start a new issue please. I reviewed OpenSSL 1.0.2h and I don't see that it calls |
|
@jay: My guess about the issue is like this: consider php which uses openssl internally, php-pgsql where libpgsql uses openssl internally, php-curl. All that three things used in one single 'php' binary. Now curl is being ended, does its cleanup and decides to free global data. Then php-openssl and php-libpgsql still try to do something openssl related where openssl needs that global data for that. Result -> crash. (but that's only my guess) Opening new issue. |
I did this
`
`
It displayed the following
`
`
Possible fix
Calling
SSL_COMP_free_compression_methods();aftercurl_global_cleanup();appears to fix the problem.See also #2561: Memory leak with SSL built-in compressions
curl/libcurl version
curl 7.48.0 (i386-pc-win32) libcurl/7.48.0 OpenSSL/1.0.2h zlib/1.2.8 WinIDN
Protocols: dict file ftp ftps gopher http https imap imaps ldap pop3 pop3s rtsp smtp smtps telnet tftp
Features: AsynchDNS IDN IPv6 Largefile SSPI Kerberos SPNEGO NTLM SSL libz
operating system
Windows 10
The text was updated successfully, but these errors were encountered: