Menu
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?
677
The best way to avoid memory leaks in C++ is to have as few new/delete calls at the program level as possible – ideally NONE. Anything that requires dynamic memory should be buried inside an RAII object that releases the memory when it goes out of scope.
The primary tools for detecting memory leaks are the C/C++ debugger and the C Run-time Library (CRT) debug heap functions. The #define statement maps a base version of the CRT heap functions to the corresponding debug version. If you leave out the #define statement, the memory leak dump will be less detailed.
In computer science, a memory leak is a type of resource leak that occurs when a computer program incorrectly manages memory allocations in a way that memory which is no longer needed is not released. A memory leak may also happen when an object is stored in memory but cannot be accessed by the running code.
A memory leak is simply dynamic memory that you allocate, but then never free. A consequence of this is that your program will slowly eat up memory over time, potentially causing a crash if you completely run out of physical memory and your swap gets completely eaten as well.
To get rid of compilation error in Joe H's answer:
sk_SSL_COMP_free(SSL_COMP_get_compression_methods());
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.
28
To get rid of the final two memory blocks allocated in SSL_library_init() try:
sk_free(SSL_COMP_get_compression_methods());
Call SSL_COMP_free_compression_methods();.
32
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
