Boost thread Leakage C ++ - PullRequest
Новая
       26

Boost thread Leakage C ++

17 голосов
/ 12 июня 2011

Может кто-нибудь дать мне знать, не подталкивает ли библиотека потоков. Мне кажется, что это делает: Google говорит, что я должен скомпилировать как буст-поток, так и pthread, который я делаю, и что в версии 1.40 эта проблема была исправлена, но я все еще получаю утечку. Обратите внимание, что это скомпилируется нормально, но обнаружены утечки. 

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

void t1(){}

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

С Valgrind я получаю следующий вывод 

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

Я также пытался использовать код, указанный на следующем веб-сайте: http://antonym.org/2009/05/threading-with-boost---part-i-creating-threads.html Все та же проблема.

1 Ответ

10 голосов
/ 12 июня 2011

Это связано с бустом 1_46_1, поэтому может быть неверно для используемой версии.Посмотрите на источники повышения, если вы действительно хотите убедить себя.(Детектор утечек в OSX не обнаруживает никаких утечек, когда я запускаю ваш пример кода).

Это не фактическая утечка (если нет ошибки в любом из pthreads, устаревшей версии надстройки, которую вы используетеили ваш компилятор).

get_once_per_thread_epoch malloc выделяет новый uintmax_t и отображает его в локальное хранилище потока с epoch_tss_key, у которого есть связанный деструктор, который освобождает сопоставленные данные.Следовательно, испорченная память гарантированно будет освобождена.

Я действительно не понимаю, почему valgrind обнаруживает это как утечку, но это может быть потому, что функции выхода pthreads выполняются в какой-то момент после функций valgrind.,Другая возможность состоит в том, что сами функции pthread протекают, но я не увидел в документации ничего, что могло бы предположить, что это так.

...