valgrind e openmp, ancora raggiungibili e possibilmente persi, è così male?

c ++ newbie qui.

Negli ultimi giorni ho migliorato le mie capacità di gestione della memoria e il mio programma non perde più memoria in base a valgrind. In effetti, non ricevo assolutamente alcun avvertimento da parte di valgrind.

Tuttavia, quando aggiungo loop di openmp nel mio codice, comincio a ottenere i seguenti errori in valgrind (memcheck): (ma nessun blocco definitivamente perso)

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

e:

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

Questo è un caso di Valgrind che non capisce l’openmp? O è qualcosa che potrebbe diventare sinistro?

Nota che quando eseguo valgrind con helgrind, ottengo migliaia di “possibili dati durante la lettura dei messaggi” (e scrivi). Tuttavia il mio programma (un risolutore di fluidodynamic) fornisce gli stessi risultati sia per i codici openmp che per quelli seriali. Posso fornire gli errori helgrind e le sezioni pertinenti se sei interessato a questo problema.

Altrimenti per ora, ecco il codice incriminato per il secondo messaggio: e la riga 943 è la linea 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; } } 

Still reachable non è una perdita di memoria.

Still reachable significa che un blocco di memoria non è stato liberato ma ci sono ancora dei puntatori validi all’inizio di quel blocco nei registri o nella memoria che non è stata liberata.

Devi dare un’occhiata alle FAQ di Valgrind . La ragione reale per cui libgomp causato l’avviso è spiegata qui .