valgrind told me, that I have following problem in my code:
LEAK SUMMARY:
==18114== definitely lost: 0 bytes in 0 blocks
==18114== indirectly lost: 0 bytes in 0 blocks
==18114== possibly lost: 1,776 bytes in 3 blocks
==18114== still reachable: 2,320 bytes in 4 blocks
==18114== suppressed: 0 bytes in 0 blocks
This problem occurs in:
#pragma omp parallel for num_threads(numThreads)
in
parallelCalc= new Calculator[numOff];
#pragma omp parallel for num_threads(numThreads)
for(int i = 1; i<=numOff;i++)
{
std::stringstream sstm;
sstm << filename <<"/" << i<<".off";
std::string aktFilename = sstm.str();
Polyhedron *poly = new Polyhedron(aktFilename.c_str());
parallelCalc[i-1].init(poly,consistentTargets->points,numTarget);
parallelCalc[i-1].hfield();
delete poly;
}
I tried to set parallelCalc shared in openmp,(I think this is the problem, isn't it?) but when I do this, I get the error MainController::parallelCalc is not a variable in clause shared
.
Could anyone give me a hint, how to solve this memory problem?
Haha it is years ago that I asked this question. The answer is simple. Fist of all "still reachable" is not an memory leak as it says in the valgrind docs
"still reachable" means your program is probably ok -- it didn't free some memory it could have. This is quite common and often reasonable. Don't use --show-reachable=yes if you don't want to see these reports.
And the other part: possibly lost: 1,776 bytes in 3 blocks
As you could read in bugzilla or also in memleak in openmp it isn’t a memory leak.
Or in words of memleak in openmp:
In short, it seems like a memory leak but it is not. It is just an issue related to OpenMP and Valgrind.