Memory leak in IntersectionOperator

[Phil Weir]

As I'm doing a large number of iterations where I call Function::eval(v,x), moving the mesh each time, I'm making heavy use of mesh().intersection_operator().clear(). On long runs with large meshes, there seems to be memory leak that grows linearly.

After some fiddling around, I think I've spotted where it comes from. When IntersectionOperator::clear() resets the pointer (_pImpl) to the IntersectionOperatorImplementation, it leaves the smart pointer to the CGAL tree hanging (IntersectionOperatorImplementation_d::tree).

In any case, adding an explicit tree.reset() to IntersectionOperatorImplementation_d seems to prevent the leak (example patch attached), although I imagine there's a more elegant way of triggering this.

To reproduce :

UnitInterval mesh(50);
double x[1] = {.5};
const Point point(1, y);

while (true)
{
  // Track memory usage
  proc_t p;
  look_up_our_self(&p);
  std::cout << p.rss << endl;

  for (int i = 0 ; i < 100 ; i++)
  {
    mesh.intersection_operator().clear();

    // Force IO to build a new tree (called by, e.g., Function::eval)
    mesh.intersection_operator().any_intersected_entity(point);
  }
}

[Andre Massing (massing)]

Thanks for reporting the bug, providing a test example and including patch. I want to dive a bit more into the code on Monday as I am wondering why the smart_pointer did not prevent the memory leak. Many thanks for your debugging work!

[Phil Weir (phil-weir)]

No worries! Hope it helps. Actually, I've also come across a slow-down problem somewhere in PETSc integration, which I'll try and track down and file today.

[Garth Wells (garth-wells)]

Has this been fixed?