OpenSSL::SSL_library_init() memory leak

Question

Recently I have started studying about memory leaks in C++, so I may ask a naive questions.
I have a c++ library that is using OpenSSL - my task is to check if there are memory leaks in this lib. I have run Visual Leak Detector to check mem leaks.
I see that the calls to SSL_library_init(); and SSL_load_error_strings(); are leading leak - quick googling is showing that at the end of usage I have to call the followings:

CONF_modules_free();
ERR_remove_state(0);
ENGINE_cleanup();
CONF_modules_unload(1);
ERR_free_strings();
EVP_cleanup();
CRYPTO_cleanup_all_ex_data();

The leak indeed decreased, but still there are two leaks(that the VLD tool shows me) that happen because the SSL_library_init call.
does anyone know what else I have to do in order to free all the mem leaks?

Solution 1

As I understand all the memory which is allocated during SSL_library_init() and SSL_load_error_strings() are stored in global variables and so it comes under the category of "Memory in Use" rather under the category of Memory leak as the memory is still accessible when the program is dying out.

One suggestion is that ERR_remove_state(0) must be called in each thread where SSL is used, because when you call the ERR_remove_state with argument 0, it just clears the error state for the current thread. Other calls appears good to me. If you could post, "two leaks" which are still being displayed by VLD, I can check.

Solution 2

To get rid of compilation error in Joe H's answer:

sk_SSL_COMP_free(SSL_COMP_get_compression_methods());

Solution 3

To get rid of the final two memory blocks allocated in SSL_library_init() try:

sk_free(SSL_COMP_get_compression_methods());

Solution 4

Call SSL_COMP_free_compression_methods();.

View more solutions

Comments

[RRR]

First, thanks!, in addtition - if I post the two leak, what do you want to see? the leak comes from the SSL_library_init() - because when I comment out this call - VLD doesn't report any leaks. I have two other questions: 1. can you please refer me to any website that I can learn more about memory leaks vs "memory in use"? 2. somehow the VLD sometimes doesnt show me the call stack for leaks that happan because OpenSSL function - do you know why? I am using OpenSSl as static lib that is compiled into my library.

[Jay]

If you post the callstack, I can help to check if there is any other free API in OpenSSL to be called. For 1: I am sorry. I am not aware of any websites. But, the point is that, till your point of application exit, if you need a memory, then it is one case of Memory in Use. The other case is that, you don't need the memory, but, you still have pointers using which you can access the memory, hence the memory is not lost and you can still free it. For 2: OpenSSL might not have been compiled in Debug mode because of which VLD is unable to extract sufficient information which can be displayed.

[Jay]

Additional Note: I got the terminology of "Memory In Use" from IBM Rational Purify tool which I generally use for testing memory leaks in Windows.

[RRR]

I dont know if I can post the call stack from this library - this library is confidential. a question regarding Purify - is Purify better than VLD? or it is just more complicated (and more expensive)? can I get a trial version of Purify ?

[Jay]

I think you should be able to get a trial version of Purify. It is quite good for Windows, but quite expensive also. You can get all the details from IBM Rational Website. I haven't used VLD myself, so can't comment on which is better.

[Jens Schwarzer]

Regarding Valgrind/Purify; I used Purify many years ago so it may have changed. But Purify instruments the code whereas Valgrind simulates the CPU. So Valgrind can be used on any program without modifcations! I believe Valgrind is much easier to use. I only had problems if I used very special CPU instructions that Valgrind couldn't simulate.

[Sergey Skopus]

that will cause memory error when openssl initialization and deinitialization is done in a loop

[Alex]

Are you sure this command exists? And is it really supposed to do something different from 4LegsDrivenCat's answer?

[avakar]

@Alex, of course it exists, github.com/openssl/openssl/blob/master/ssl/ssl_ciph.c#L1909 and it's the correct way (as far as the word "correct" can be applied to OpenSSL) to free up the compression methods list. Freeing up the pointer manually will clearly leave a dangling pointer somewhere.

[Alex]

Ok, you're right. Which header do I need to include to get access to this function? I included all the headers listed in the file you showed me and ssl_locl.h wasn't there (and the others didn't have it). I installed the most recent version of OpenSSL from Shining Light Productions, i.e. 1.0.2a

[Alex]

Ok, your function is pretty new, as it wasn't there in 1.0.1L, but 1.0.2a has it. I experimented and found that OpenSSL doesn't like it if I call both yours and the one 4Legs mentioned, but they seem to serve the same purpose if I call only one of them. And in case anyone who comes after me wonders: I had to include ssl.h.