memory leak when using gmsh::model::occ::synchronize()?
Hi. my code is very short, and I use Valgrind to check memory leak.
#include <gmsh.h>
#include <iostream>
#include <vector>
using namespace std;
int main()
{
gmsh::initialize();
gmsh::option::setNumber("General.Verbosity", 2); // default level is 5
double lc = 0;
gmsh::model::occ::addPoint(0., 0., 0., lc, 1);
gmsh::model::occ::addPoint(0., 10., 0., lc, 2);
gmsh::model::occ::addPoint(10., 10., 0., lc, 3);
gmsh::model::occ::addPoint(10., 0., 0., lc, 4);
gmsh::model::occ::addLine(1, 2, 1);
gmsh::model::occ::addLine(2, 3, 2);
gmsh::model::occ::addLine(3, 4, 3);
gmsh::model::occ::addLine(4, 1, 4);
std::vector<int> curveloop1 = {1, 2, 3, 4};
gmsh::model::occ::addCurveLoop(curveloop1, 1);
std::vector<int> surfaceloop1 = {1};
gmsh::model::occ::addPlaneSurface(surfaceloop1, 1);
gmsh::model::occ::synchronize();
// second polygon----------------------------
gmsh::model::occ::addPoint(5., 1., -5., lc, 5);
gmsh::model::occ::addPoint(5., 11., -5., lc, 6);
gmsh::model::occ::addPoint(5., 11., 5., lc, 7);
gmsh::model::occ::addPoint(5., 1., 5., lc, 8);
gmsh::model::occ::addLine(5, 6, 5);
gmsh::model::occ::addLine(6, 7, 6);
gmsh::model::occ::addLine(7, 8, 7);
gmsh::model::occ::addLine(8, 5, 8);
std::vector<int> curveloop2 = {5, 6, 7, 8};
gmsh::model::occ::addCurveLoop(curveloop2, 2);
std::vector<int> surfaceloop2 = {2};
gmsh::model::occ::addPlaneSurface(surfaceloop2, 2);
gmsh::model::occ::synchronize();
//-------------
std::vector<std::pair<int, int>> out;
std::vector<std::vector<std::pair<int, int>>> outmap;
gmsh::model::occ::fragment({{2, 1}}, {{2, 2}}, out, outmap);
gmsh::model::occ::synchronize();
gmsh::model::mesh::generate(2);
//gmsh::fltk::run();
gmsh::model::mesh::clear();
gmsh::clear();
gmsh::finalize();
return 0;
}
and I got
==9105== Memcheck, a memory error detector
==9105== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al.
==9105== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info
==9105== Command: ./main
==9105==
==9105==
==9105== HEAP SUMMARY:
==9105== in use at exit: 71,375 bytes in 200 blocks
==9105== total heap usage: 24,827 allocs, 24,627 frees, 5,109,030 bytes allocated
==9105==
==9105== 9,712 (456 direct, 9,256 indirect) bytes in 1 blocks are definitely lost in loss record 142 of 145
==9105== at 0x4C3217F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9105== by 0x549E8DE: OCC_Internals::synchronize(GModel*) (GModelIO_OCC.cpp:4412)
==9105== by 0x10B427: main (main.cpp:30)
==9105==
==9105== 9,712 (456 direct, 9,256 indirect) bytes in 1 blocks are definitely lost in loss record 143 of 145
==9105== at 0x4C3217F: operator new(unsigned long) (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9105== by 0x549E8DE: OCC_Internals::synchronize(GModel*) (GModelIO_OCC.cpp:4412)
==9105== by 0x10B676: main (main.cpp:47)
==9105==
==9105== LEAK SUMMARY:
==9105== definitely lost: 912 bytes in 2 blocks
==9105== indirectly lost: 18,512 bytes in 142 blocks
==9105== possibly lost: 0 bytes in 0 blocks
==9105== still reachable: 51,951 bytes in 56 blocks
==9105== suppressed: 0 bytes in 0 blocks
==9105== Reachable blocks (those to which a pointer was found) are not shown.
==9105== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==9105==
==9105== For counts of detected and suppressed errors, rerun with: -v
==9105== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0)
I have to run similar code many times in parallelization. So, can we solve the memory problem?