2015-11-06 52 views
2

内存泄漏我有征是推动我疯了的问题。每当我尝试重新分配存储在std :: vector中的一组Eigen :: MatrixXd时,我都会从valgrind获取内存泄漏。与本征+的std ::矢量+ OpenMP的

我已经重写了我的代码至少5次,我试过用std :: maps(这是我最初的解决方案的一部分),我已经从载体向量移动到纯向量....没有工作。只要我添加我的openMP指令,就会发生泄漏。

这里有一个最小的工作示例:

#include <iostream> 
#include <Eigen/Dense> 
#include <vector> 
#include <omp.h> 

typedef Eigen::Matrix< float, Eigen::Dynamic, Eigen::Dynamic, Eigen::RowMajor > EMat; 

EMat function() { 
     EMat a(19,29); 
     return a; 
} 

int main() { 
     std::vector <EMat> v(10); 

#pragma omp parallel for schedule(dynamic) 
     for (unsigned int i = 0; i < 10; ++i) { 
       v[i] = function(); 
     } 
} 

如果我尝试使用Valgrind的运行它,我得到:

[email protected] ~/tmp $ valgrind --leak-check=full --show-leak-kinds=all ./test_leak==9640== Memcheck, a memory error detector 
==9640== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al. 
==9640== Using Valgrind-3.10.0.SVN and LibVEX; rerun with -h for copyright info 
==9640== Command: ./test_leak 
==9640== 
==9640== 
==9640== HEAP SUMMARY: 
==9640==  in use at exit: 4,632 bytes in 10 blocks 
==9640== total heap usage: 31 allocs, 21 frees, 48,952 bytes allocated 
==9640== 
==9640== 72 bytes in 1 blocks are still reachable in loss record 1 of 4 
==9640== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==9640== by 0x4C2CF1F: realloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==9640== by 0x513F7F8: gomp_realloc (alloc.c:54) 
==9640== by 0x51439FA: gomp_team_start (team.c:376) 
==9640== by 0x51412E9: GOMP_parallel_loop_dynamic_start (loop.c:466) 
==9640== by 0x400EBD: main (test_leak.cpp:19) 
==9640== 
==9640== 192 bytes in 1 blocks are still reachable in loss record 2 of 4 
==9640== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==9640== by 0x513F7A8: gomp_malloc (alloc.c:36) 
==9640== by 0x5143B8E: gomp_team_start (team.c:190) 
==9640== by 0x51412E9: GOMP_parallel_loop_dynamic_start (loop.c:466) 
==9640== by 0x400EBD: main (test_leak.cpp:19) 
==9640== 
==9640== 2,128 bytes in 7 blocks are possibly lost in loss record 3 of 4 
==9640== at 0x4C2CC70: calloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==9640== by 0x4012E54: _dl_allocate_tls (dl-tls.c:296) 
==9640== by 0x5C33DA0: [email protected]@GLIBC_2.2.5 (allocatestack.c:589) 
==9640== by 0x5143905: gomp_team_start (team.c:439) 
==9640== by 0x51412E9: GOMP_parallel_loop_dynamic_start (loop.c:466) 
==9640== by 0x400EBD: main (test_leak.cpp:19) 
==9640== 
==9640== 2,240 bytes in 1 blocks are still reachable in loss record 4 of 4 
==9640== at 0x4C2AB80: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) 
==9640== by 0x513F7A8: gomp_malloc (alloc.c:36) 
==9640== by 0x51434D5: gomp_new_team (team.c:144) 
==9640== by 0x51405FC: gomp_parallel_loop_start (loop.c:447) 
==9640== by 0x51412E9: GOMP_parallel_loop_dynamic_start (loop.c:466) 
==9640== by 0x400EBD: main (test_leak.cpp:19) 
==9640== 
==9640== LEAK SUMMARY: 
==9640== definitely lost: 0 bytes in 0 blocks 
==9640== indirectly lost: 0 bytes in 0 blocks 
==9640==  possibly lost: 2,128 bytes in 7 blocks 
==9640== still reachable: 2,504 bytes in 3 blocks 
==9640==   suppressed: 0 bytes in 0 blocks 
==9640== 
==9640== For counts of detected and suppressed errors, rerun with: -v 
==9640== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) 

我搜索在网络上花了很多时间和试验,但没有运气。 任何人都可以帮助我吗?

在此先感谢!

[R

+0

OpenMP泄漏它不是因为你的代码。不要花太多时间在这... – coincoin

+0

我同意@币币。您可以使用[抑制器(http://valgrind.org/docs/manual/manual-core.html#manual-core.suppress),以抑制OpenMP的泄漏 – Brahim

回答

2

这并不是因为征也不std::vector因为OpenMP的的但是“泄露”或相当的valgrind报告不是“可信”。

如上所述,不要在此花费太多时间,您对这些泄漏不承担任何责任。

见相关链接:

至于我可以告诉libgomp不杀它催生了执行结束线程,使得内核清理做到这一点。

在libgomp情况下,大部分的分配在退出时间仍可达 落入他们真的不能被释放的范畴。

+1

谢谢大家对你的答案! – RH6

+0

@ RH6 np欢迎来到SO! – coincoin