Boost thread Leakage C++

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.

Have a look at src/pthread/Once.cpp in the boost sources. It is pretty clear that it doesn't leak (just look up the definitions of the pthread library functions that it uses). — Mankarse, Jun 12 '11 at 11:23
Using `std::thread` instead of boost, the code doesn't even run for me; it terminates with a `std::system_error` exception. — Kerrek SB, Jun 12 '11 at 11:41
just try the code in the link above and you most probably would see the leak from valgrind — Testboo Boos, Jun 12 '11 at 18:32

score 10 · Accepted Answer · edited Dec 30 '13 at 07:45

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.

Thank you. I upgraded to 1.46.1 and same error from valgrind. Coding with pthread directly does not cause this error. Must be like you said cleaning of thread is done after valgrind can detect — Testboo Boos, Jun 12 '11 at 18:33

Boost thread Leakage C++

1 Answers1

Linked