Valgrind и openmp, все еще достижимые и, возможно, потерянные, это плохо?

С++ новичок здесь.

Я улучшаю свои навыки управления памятью в течение последних нескольких дней, и моя программа больше не теряет память в соответствии с 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: [email protected]@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? Или это может стать зловещим?

Обратите внимание, что когда я запускаю valgrind с helgrind, я получаю тысячи "возможных расхождений данных при чтении" (и записи) сообщений. Однако моя программа (решатель динамики жидкости) дает одинаковые результаты как для openmp, так и для последовательных кодов. Я могу предоставить ошибки helgrind и соответствующие разделы, если вы заинтересованы в этом для этой проблемы.

В противном случае на данный момент здесь приведен код нарушения для второго сообщения: а строка 943 - это прагма.

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

Ответ 1

Still reachable не утечка памяти.

Still reachable означает, что блок памяти не был освобожден, но все еще существуют действительные указатели на начало этого блока в регистрах или памяти, которые не были освобождены.

Вам нужно взглянуть на часто задаваемые вопросы Valgrind. Фактическая причина libgomp, вызывающая предупреждение, объясняется здесь.