valgrind和openmp仍然可以访问甚至可能丢失，那很糟糕吗? [英] valgrind and openmp, still reachable and possibly lost, is that bad?

问题描述

c ++新手在这里.

c++ newbie here.

最近几天，我一直在提高自己的内存管理技能，根据valgrind的说法，我的程序不再泄漏内存.实际上，我根本没有收到valgrind的警告.

I've been improving my memory management skills over the last few days, and my program no longer leaks memory according to valgrind. In fact, I get no warnings from valgrind at all.

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

However, when I add openmp loops into my code, I start to get the following errors in valgrind (memcheck): (but no definitely lost blocks)

==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的情况吗?还是它可能变得险恶?

Is this a case of valgrind not understanding the openmp? Or is it something that might become sinister?

请注意，当我与helgrind一起运行valgrind时，会出现数千条在读取"(和写入)消息期间可能发生的数据竞争.但是，我的程序(流体动力学求解器)为openmp和串行代码提供了相同的结果.如果您对此问题感兴趣，可以提供helgrind错误和相关章节.

Note that when I run valgrind with helgrind, I get thousands of "possible data race during read" (and write) messages. However my program (a fluid dynamics solver) gives the same results for both the openmp and serial codes. I can provide the helgrind errors and relevant sections if you are interested in that for this problem.

否则，现在，这是第二条消息的冒犯代码:第943行是编译指示行.

Otherwise for now, here is the offending code for the second message: and line 943 is the pragma line.

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;
    }
}

推荐答案

Still reachable 不是内存泄漏.

Still reachable表示尚未释放一个内存块，但在尚未释放的寄存器或内存中仍然存在指向该块开始的有效指针.

Still reachable means that a block of memory has not been freed but there are still valid pointers to the start of that block in registers or memory that has not been freed.

您需要查看 Valgrind常见问题解答 . 此处 .

You need to have a look at the Valgrind FAQ. The actual reason for libgomp causing the warning is explained here.

这篇关于valgrind和openmp仍然可以访问甚至可能丢失，那很糟糕吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！