2012-12-12 69 views
0

我正在尝试加强线程,并且我从valgrind注意到,它仅仅通过循环访问一个空的代码块而泄露了320个字节。我在2010年的谷歌上发现了一些帖子,表明它们可能是Valgind运行之前没有关闭的线程的误判,但是这略有不同。在这些示例中,您有几块仍然可以访问的块(因此,如果线程仍在运行,则可以自由运行),我的运行显示8仍然可以到达,而20块肯定丢失。这是我应该担心的事情,还是我有些想念什么?感谢升压线程中的内存泄漏?

代码

#include <boost/thread.hpp> 
#include <iostream> 
#define THREADS 20 

void threadfunc(int workerid) {} 

int main(int argc, char **argv){ 

    boost::thread *threads[THREADS]; 
    int i; 
    for (i = 0; i < THREADS; i++) { 
     threads[i] = new boost::thread(threadfunc, i); 
    } 
    for (i = 0; i < THREADS; i++) { 
     threads[i]->join(); 
    } 
} 

编译命令

c++ -o example example.cpp -I /usr/include/boost -lboost_system -lboost_thread 

Valgind命令

G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind -v --tool=memcheck --leak-check=full --show-reachable=yes --num-callers=40 --log-file=valgrind.log ./example 

Valgine导致

==31674== HEAP SUMMARY: 
==31674==  in use at exit: 328 bytes in 21 blocks 
==31674== total heap usage: 103 allocs, 82 frees, 14,968 bytes allocated 
==31674== 
==31674== Searching for pointers to 21 not-freed blocks 
==31674== Checked 215,920 bytes 
==31674== 
==31674== 8 bytes in 1 blocks are still reachable in loss record 1 of 2 
==31674== at 0x4C2B6CD: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==31674== by 0x4E454A9: boost::detail::get_once_per_thread_epoch() (in /usr/lib/libboost_thread.so.1.46.1) 
==31674== by 0x4E3E4FF: ??? (in /usr/lib/libboost_thread.so.1.46.1) 
==31674== by 0x4E3E7C8: boost::detail::get_current_thread_data() (in /usr/lib/libboost_thread.so.1.46.1) 
==31674== by 0x4E3FF3A: boost::thread::join() (in /usr/lib/libboost_thread.so.1.46.1) 
==31674== by 0x402C79: main (in /home/Jason/php/base/example) 
==31674== 
==31674== 320 bytes in 20 blocks are definitely lost in loss record 2 of 2 
==31674== at 0x4C2B1C7: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==31674== by 0x402C2A: main (in /home/Jason/php/base/example) 
==31674== 
==31674== LEAK SUMMARY: 
==31674== definitely lost: 320 bytes in 20 blocks 
==31674== indirectly lost: 0 bytes in 0 blocks 
==31674==  possibly lost: 0 bytes in 0 blocks 
==31674== still reachable: 8 bytes in 1 blocks 
==31674==   suppressed: 0 bytes in 0 blocks 
==31674== 
==31674== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) 
--31674-- 
--31674-- used_suppression:  2 dl-hack3-cond-1 
==31674== 
==31674== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 2 from 2) 
+0

“仍可达”的8个字节是我在每次使用boost-thread的valgrind运行中看到的。所以,我认为这很正常(可能是他们必须做的事情),而且它似乎并不依赖于线程的数量或者随着线程数量的增加而增长,它可能是一些独特的全球数据,不会被释放(有意)。无论如何,这个记忆将被回收,所以它没有真正的关注。 ForEveR指出,对于另外20个“绝对丢失”的块,很显然,这些20个线程缺少'delete'调用。 –

+0

谢谢,不,它似乎不会增长。我昨天运行了一个线程PHP核心的测试,并且在重新创建了10个线程1000多次和3,000,000+个分配(是的,即6个零)之后,一个8字节块是唯一的问题。 – JSON

回答

4

这是你的错误,而不是boost::thread s。 你的记忆没有被释放。

for (i = 0; i < THREADS; i++) { 
    threads[i] = new boost::thread(threadfunc, i); 
} 

退出主函数之前,您必须释放内存(删除线程)。 类似于

for (i = 0; i < THREADS; i++) { 
    delete threads[i]; 
} 

或在加入后下一次删除。

+0

我的不好......... – JSON

+0

我几乎掉在了我的那把剑上。这证明,即使咖啡不能让我们继续30小时后大声笑 – JSON

+0

我有同样的问题。使用“* _epoch”功能。但是,我不新增加boost :: thread。我的线程在main中分配在堆栈上。我加入他们,然后从主返回。我想知道你是否知道删除这个错误(除了抑制)。它似乎来自于提振,但是 - 课程 - 它也可能是我正在做的事情。 – Bitdiot