【问题标题】:valgrind and openmp, still reachable and possibly lost, is that bad?valgrind 和 openmp,仍然可以访问并且可能丢失,这很糟糕吗?
【发布时间】:2017-09-14 05:46:12
【问题描述】:

这里是c++新手。

在过去的几天里,我一直在提高我的内存管理技能,并且我的程序不再根据 valgrind 泄漏内存。事实上,我根本没有收到 valgrind 的警告。

但是,当我在代码中添加 openmp 循环时,我开始在 valgrind (memcheck) 中收到以下错误:(但没有绝对丢失的块)

==6417== 304 bytes in 1 blocks are possibly lost in loss record 3 of 4
==6417==    at 0x4C279FC: calloc (vg_replace_malloc.c:467)
==6417==    by 0x4011868: _dl_allocate_tls (dl-tls.c:300)
==6417==    by 0x6649871: pthread_create@@GLIBC_2.2.5 (allocatestack.c:570)
==6417==    by 0x62263DF: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==6417==    by 0x42A2BB: Blade::updatePanels() (blade.cpp:187)
==6417==    by 0x418677: VLMsolver::initialiseBlade() (vlmsolver.cpp:590)
==6417==    by 0x415A1B: VLMsolver::start(std::string) (vlmsolver.cpp:80)
==6417==    by 0x40B28C: main (charybdis.cpp:176)

和:

==6417== 1,568 bytes in 1 blocks are still reachable in loss record 4 of 4
==6417==    at 0x4C28FAC: malloc (vg_replace_malloc.c:236)
==6417==    by 0x6221578: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==6417==    by 0x6226044: ??? (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==6417==    by 0x622509B: GOMP_parallel_start (in /usr/lib/x86_64-linux-gnu/libgomp.so.1.0.0)
==6417==    by 0x41AF58: VLMsolver::segmentCirculations() (vlmsolver.cpp:943)
==6417==    by 0x415E4B: VLMsolver::solveManager() (vlmsolver.cpp:177)
==6417==    by 0x415A4B: VLMsolver::start(std::string) (vlmsolver.cpp:91)
==6417==    by 0x40B28C: main (charybdis.cpp:176)

这是 valgrind 不了解 openmp 的情况吗?还是会变得险恶?

请注意,当我使用 helgrind 运行 valgrind 时,我会收到数以千计的“读取期间可能的数据竞争”(和写入)消息。然而,我的程序(流体动力学求解器)对 openmp 和串行代码给出了相同的结果。如果您对此问题感兴趣,我可以提供 helmind 错误和相关部分。

否则,这里是第二条消息的违规代码:第 943 行是 pragma 行。

for (int b = 0;b < sNumberOfBlades;++b) {
*VLMSOLVER.CPP LINE 943 is next*:
#pragma omp parallel for collapse(2) num_threads(2) firstprivate(b) 
    for (int i = 0;i<numX;++i) {
        for (int j = 0;j<numY;++j) {
            if (j == 0) {
                blades[b].line[i*numNodesY+j].circulation = blades[b].panel[i*numY+j].circulation;
            } else {
                blades[b].line[i*numNodesY+j].circulation =  blades[b].panel[i*numY+j].circulation - blades[b].panel[i*numY+j-1].circulation;
            }
            if (j==numY-1) {
                blades[b].line[i*numNodesY+j+1].circulation = -1 * blades[b].panel[i*numY+j].circulation;
            }

        }
    }
    if (sBladeSymmetry) {
        break;
    }
}

int k = numX*numNodesY;
for (int b = 0;b < sNumberOfBlades;++b) {
    for (int i = 0;i<numX;++i) {
        for (int j = 0;j<numY;++j) {
            if (i == 0) {
                blades[b].line[k+i*numY+j].circulation = - 1 * blades[b].panel[i*numY+j].circulation;
            } else {
                blades[b].line[k+i*numY+j].circulation = -1 * blades[b].panel[i*numY+j].circulation + blades[b].panel[(i-1)*numY+j].circulation;
            }
            if (i==numX-1) {
                blades[b].line[k+(i+1)*numY+j].circulation =  blades[b].panel[i*numY+j].circulation;
            }
        }
    }
    if (sBladeSymmetry) {
        break;
    }
}

【问题讨论】:

    标签: c++ openmp valgrind


    【解决方案1】:

    Still reachable 不是内存泄漏。

    Still reachable 表示一块内存还没有被释放,但在寄存器或内存中仍有有效的指向该块开始的指针没有被释放。

    您需要查看 the Valgrind FAQhere 解释了libgomp 引起警告的实际原因。

    【讨论】:

    • 所以让内存仍然可以访问是 openmp 的一个特性,就像链接中的 STL 案例一样?
    • @CptLightning:我相信是这样,但我并没有真正使用过 OpenMP,所以我不能确定是否是这种情况。您需要查看 OpenMP 是否也使用与 STL 相同的基本原理,链接对此进行了解释和讨论。
    • 知道为什么 valgrind 也会报告 possibly lost 吗?我今天仍然可以重现它。
    猜你喜欢
    • 2011-05-23
    • 2019-01-24
    • 2016-04-11
    • 1970-01-01
    • 1970-01-01
    • 2011-04-05
    • 2023-03-29
    • 2013-07-11
    相关资源
    最近更新 更多