Boost 线程泄漏 C++
有人可以告诉我 boost 线程库是否泄漏吗?在我看来,确实如此: Google 说我应该使用我正在做的 boost 线程和 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 还是同样的问题。
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.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
这与 boost 1_46_1 有关,因此对于您正在使用的版本可能不正确。如果你真的想说服自己,请查看增强源。 (当我运行示例代码时,OSX 上的泄漏检测器没有检测到任何泄漏)。
这不是真正的泄漏(除非 pthreads、您正在使用的过时版本的 boost 或您的编译器存在错误)。
get_once_per_thread_epoch
malloc 一个新的uintmax_t
并使用epoch_tss_key
将其映射到线程本地存储,该键具有一个关联的析构函数,可释放映射的数据。因此,保证释放分配的内存。我真的不明白为什么 valgrind 将此检测为泄漏,但这可能是因为 pthreads 退出函数在 valgrind 函数之后的某个时刻执行。另一种可能性是 pthread 函数本身正在泄漏,但我在文档中没有看到任何表明这种情况的内容。
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 newuintmax_t
and maps it into thread-local-storage with aepoch_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.