valgrind y openmp, todavía alcanzables y posiblemente perdidos, ¿es malo?

Question

C++ newbie aquí.

he ido mejorando mis habilidades de gestión de memoria en los últimos días, y mi programa ya no pérdidas de memoria de acuerdo con valgrind. De hecho, no recibo ninguna advertencia de valgrind en absoluto.

Sin embargo, cuando agrego openmp bucles en mi código, comienzo a conseguir los siguientes errores en valgrind (Memcheck): (pero no bloquea definitivamente perdidos)

==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) 

y:

==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) 

¿Es este un caso de valgrind sin entender el openmp? ¿O es algo que podría volverse siniestro?

Tenga en cuenta que cuando corro valgrind con Helgrind, consigo miles de "posible carrera de datos durante la lectura" (y escribir) los mensajes. Sin embargo, mi programa (un solucionador de dinámica de fluidos) da los mismos resultados para los códigos de apertura y de serie. Puedo proporcionar los errores de Helgrind y las secciones relevantes si le interesa este problema.

De lo contrario, por ahora, aquí está el código infractor por el segundo mensaje: y la línea 943 es la línea 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; 
    } 
} 

Answer 1

Still reachable no es una pérdida de memoria.

Still reachable significa que no se ha liberado un bloque de memoria pero todavía hay punteros válidos para el inicio de ese bloque en los registros o la memoria que no se ha liberado.

Debe echar un vistazo a the Valgrind FAQ. La razón real de libgomp causa la advertencia se explica here.