Databases
StackOverflow2013
Postsdbo
POBoost Shared Pointers and Memory Management
 

Note that there are some explanatory texts on larger screens.

plurals
  1. POBoost Shared Pointers and Memory Management
    primarykey
    data
    text
    <p>I began using boost rather recently and am impressed by the functionality and APIs provided. </p> <p>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. </p> <p>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? </p> <p>Thank you.</p> <p>EDIT1:</p> <p>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:</p> <pre><code>==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&lt;apache::thrift::transport::TSSLSocketFactory&gt;(apache::thrift::transport::TSSLSocketFactory*) (checked_delete.hpp:34) ==6813== by 0x42ADE3: boost::detail::sp_counted_impl_p&lt;apache::thrift::transport::TSSLSocketFactory&gt;::dispose() (sp_counted_impl.hpp:78) </code></pre> <p>Does this mean that it is the thrift code that is leaking memory?</p> <p>Thanks.</p>
    singulars
    1. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. PTQuestion
    1. USIzza
    1. USIzza
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. PO
      singulars
      1. PTAnswer
    2. PO
      singulars
      1. PTAnswer
    1. This table or related slice is empty.
    1. COCan you provide a minimal compilable example that demonstrates the leak?
      singulars
      1. POBoost Shared Pointers and Memory Management
      1. USFred Larson
    2. COUsually `shared_ptr` managed memory is deallocated when the reference count goes to zero. If this is not the case there might be various reasons depending on how your application uses the `shared_ptr`. Worst is you could have circular references with shared pointers in your class structures, in this case the allocated memory will never be deallocated at all AFAIK.
      singulars
      1. POBoost Shared Pointers and Memory Management
      1. USπάντα ῥεῖ
    3. COWhat @g-makulik said; the operative keyword to find a solution to that is `weak_ptr`
      singulars
      1. POBoost Shared Pointers and Memory Management
      1. USsehe
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload