CODEWITHSUNDEEP
c++boostmemory-leaksshared-ptr
Izza
Izza

Reputation: 2419

Boost Shared Pointers and Memory Management

I began using boost rather recently and am impressed by the functionality and APIs provided.

In using boost::shared_ptr, when I check the program with Valgrind, I found a considerable number of "Still reachable" memory leaks. As per the documentation of Valgrind, these are not a problem. However, since I used to use the standard C++ library only, I always made sure that any program written is completely free from memory leaks.

My question is, are these memory leaks something to worry about? I tried using reset(), however it only decrements the reference count, doesn't deallocate memory. Can I safely ignore these, or any way to forcibly deallocate the memory allocated by boost::shared_ptr?

Thank you.

EDIT1:

I'm using apache thrift in this code. Further checking with valigrind, with the option --show-reachable=yes, almost all of the leak messages are similar to below:

==6813== 24 bytes in 1 blocks are still reachable in loss record 3 of 21
==6813==    at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6813==    by 0x5E7A783: CRYPTO_malloc (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==6813==    by 0x5EF524A: lh_insert (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==6813==    by 0x5E7BC17: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==6813==    by 0x5E7C268: ??? (in /lib/x86_64-linux-gnu/libcrypto.so.1.0.0)
==6813==    by 0x5BF43C5: SSL_CTX_free (in /lib/x86_64-linux-gnu/libssl.so.1.0.0)
==6813==    by 0x4E9574F: apache::thrift::transport::SSLContext::~SSLContext() (TSSLSocket.cpp:71)
==6813==    by 0x4E95768: apache::thrift::transport::SSLContext::~SSLContext() (TSSLSocket.cpp:74)
==6813==    by 0x4E96C08:  apache::thrift::transport::TSSLSocketFactory::~TSSLSocketFactory() (sp_counted_base_gcc_x86.hpp:145)
==6813==    by 0x4E96C98: apache::thrift::transport::TSSLSocketFactory::~TSSLSocketFactory() (TSSLSocket.cpp:369)
==6813==    by 0x42A986: void boost::checked_delete<apache::thrift::transport::TSSLSocketFactory>(apache::thrift::transport::TSSLSocketFactory*) (checked_delete.hpp:34)
==6813==    by 0x42ADE3: boost::detail::sp_counted_impl_p<apache::thrift::transport::TSSLSocketFactory>::dispose() (sp_counted_impl.hpp:78)

Does this mean that it is the thrift code that is leaking memory?

Thanks.

Upvotes: 0

Views: 771

Answers (2)

guilespi
guilespi

Reputation: 4702

Usually if the memory is still reachable it's not a leak. If you define a leak as some memory you've reserved using malloc/new but you cannot release it anymore, as in

//this leaks since p is unreachable outside the scope
int main() {
  char * p = (char*)malloc(10);
  return 0; 
}

You can have a situation where your memory always grows but it's not technically a leak, e.g. you have a global list you always put things in but never put them out. In that case the list memory is reachable and you could free it.

Having said that, by the call stack pasted in your question, it seems the referenced memory is some allocation done by libcrypto when destroying the thrift SSL transport.

So your shared pointer is not the problem, most probably is just buffered memory used inside libcrypto.

Upvotes: 2

doron
doron

Reputation: 28872

Take a look at http://www.gnu.org/software/libc/manual/html_node/Statistics-of-Malloc.html#Statistics-of-Malloc

If uordblks at the start of your program are the same as those at the end, you have no leaks. since you have managed to free all the memory you have allocated.

Upvotes: 2

Related Questions