Question

Could someone let me know whether boost thread library leaks. It seems to me that it does:
Google says that I should compile with both boost thread and pthread which I am doing and that in version 1.40 this problem has been fixed but I still get leakage. Note that this will compile fine but leaks are detected.

#include <boost/thread.hpp>  
#include <boost/date_time.hpp>  

void t1(){}

int main(void){
boost::thread th1(t1);
th1.join();
return 1;
}

With Valgrind I get the following output

HEAP SUMMARY:
==8209==     in use at exit: 8 bytes in 1 blocks
==8209==   total heap usage: 5 allocs, 4 frees, 388 bytes allocated
==8209== 
==8209== 8 bytes in 1 blocks are still reachable in loss record 1 of 1
==8209==    at 0x4024F20: malloc (vg_replace_malloc.c:236)
==8209==    by 0x4038CCB: boost::detail::get_once_per_thread_epoch() (in /usr/local/lib/libboost_thread.so.1.42.0)
==8209==    by 0x40329D4: ??? (in /usr/local/lib/libboost_thread.so.1.42.0)
==8209==    by 0x4032B26: boost::detail::get_current_thread_data() (in /usr/local/lib/libboost_thread.so.1.42.0)
==8209==    by 0x4033F32: boost::thread::join() (in /usr/local/lib/libboost_thread.so.1.42.0)
==8209==    by 0x804E7C3: main (testboost.cpp)
==8209== 
==8209== LEAK SUMMARY:
==8209==    definitely lost: 0 bytes in 0 blocks
==8209==    indirectly lost: 0 bytes in 0 blocks
==8209==      possibly lost: 0 bytes in 0 blocks
==8209==    still reachable: 8 bytes in 1 blocks
==8209==         suppressed: 0 bytes in 0 blocks

I also tried with the code listed at the following website: http://antonym.org/2009/05/threading-with-boost—part-i-creating-threads.html
Still the same problem.

Answer 1

This is in relation to boost 1_46_1, so it may not be true for the version that you are using. Look at the boost sources if you really want to convince yourself. (The leak detector on OSX does not detect any leaks when I run your example code).

This is not an actual leak (unless there is a bug with either pthreads, the outdated version of boost that you are using, or your compiler).

get_once_per_thread_epoch mallocs a new uintmax_t and maps it into thread-local-storage with a epoch_tss_key that has an associated destructor that frees the mapped data. Therefore the malloced memory is guaranteed to be freed.

I really don’t understand why valgrind is detecting this as a leak, but it may be because the the pthreads exit functions are executing at some point after the valgrind ones. The other possibility is that the pthread functions themselves are leaking, but I didn’t see anything in the documentation that would suggest that this is the case.