CODEWITHSUNDEEP
c++memory-leaksvalgrindboost-thread
Hector
Hector

Reputation: 1220

Still Reachable Memory after all in scope pointers are Freed

In my main function I create three objects with new. I then delete them. Running through Valgrind shows 8 bytes of still reachable memory. I have tried sticking the entire main function in a loop so it runs multiple times. It is still only 8 bytes.

My Main -

int main()
{
    settings *st = new settings();
    thread_data *td = new thread_data(st);
    client_handler *cl = new client_handler(td);

    delete cl;
    delete td;
    delete st;
}

The relevant valgrind output -

==24985== 8 bytes in 1 blocks are still reachable in loss record 1 of 1
==24985==    at 0x4C2CD7B: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==24985==    by 0x4E494F9: boost::detail::get_once_per_thread_epoch() (in /usr/lib/libboost_thread.so.1.49.0)
==24985==    by 0x4E4182F: ??? (in /usr/lib/libboost_thread.so.1.49.0)
==24985==    by 0x4E41B08: boost::detail::get_current_thread_data() (in /usr/lib/libboost_thread.so.1.49.0)
==24985==    by 0x4E41D58: boost::this_thread::interruption_enabled() (in /usr/lib/libboost_thread.so.1.49.0)
==24985==    by 0x4E41D88: boost::this_thread::disable_interruption::disable_interruption() (in /usr/lib/libboost_thread.so.1.49.0)
==24985==    by 0x421854: boost::shared_mutex::lock_upgrade() (shared_mutex.hpp:195)
==24985==    by 0x423A3B: boost::upgrade_lock<boost::shared_mutex>::lock() (locks.hpp:875)
==24985==    by 0x422FA6: boost::upgrade_lock<boost::shared_mutex>::upgrade_lock(boost::shared_mutex&) (locks.hpp:766)
==24985==    by 0x41E15C: settings::load() (settings.cpp:91)
==24985==    by 0x41D796: settings::settings() (settings.cpp:34)
==24985==    by 0x40A3BB: main (main.cpp:26)

settings::load() is called only once, from the constructor. Line 91 is the first line -

bool settings::load()
{
    boost::upgrade_lock<boost::shared_mutex> lock(_access);
    boost::upgrade_to_unique_lock<boost::shared_mutex> uniqueLock(lock);

I don't understand how the memory is still reachable. The settings object is deleted. _access should be deleted when the settings constructor is called (it is a member of settings). I have tried changing _access to a pointer & allocating / deleting in the constructor/destructors to no avail. The upgrade lock should be deconstructed when it goes out of scope.

Even if there is a memory leak (as far as I can find there are is no known bug in boost::thread (version 1.49)) surely the memory should be lost?

I realise this isn't a major issue but it is an irritation (and a peer is not letting me forget about it)

Any ideas?

Upvotes: 1

Views: 618

Answers (1)

oliver
oliver

Reputation: 6771

According to Boost thread Leakage C++ and http://boost.2283326.n4.nabble.com/thread-Memory-leak-in-Boost-Thread-td2648030.html this is not an actual memory leak in Boost but rather a problem in Valgrind.

IIUC the leak is reported because Boost frees the memory at a time when Valgrind can't detect this anymore. From the second link:

Is that really a memory leak?

most likely not. the memory in question is freed by a deleter of pthread_key_create, which means when the (main) thread is exited. valgrind apparently does the leak checking before that.

While there are discussions about whether this isn't a Boost bug anyway, I think you shouldn't be worried about this problem for your application: it's (a) a one-time leak which doesn't grow and (b) not caused by a problem in your code.

Upvotes: 3

Related Questions