which method/tool is best to check memory leak for VTK programs on Ubuntu? vtkDebugLeaks enough? or Valgrind/ASan?

Support
1

which method/tool is best to check memory leak for VTK programs on Ubuntu? vtkDebugLeaks enough? or Valgrind/ASan?
thanks

2

VTK_DEBUG_LEAKS

3

thanks!
may i ask it’s added since which version of VTK?
using it is enough to detect memory leaks, as Valgrind and ASan?

4

VTK_DEBUG_LEAKS is old, while the link I shared is only present in VTK 9.

Valgrind and Asan will find more potential leaks but will have a lot of false positive as they rely on monitoring the memory directly (kindof).

VTK _DEBUG_LEAKS will find all vtkObject that are not correct deallocated.

5

thanks, also find VTK_DEBUG_LEAKS in vtk-8.1, so what’s ur suggestion on Ubuntu? just use VTK_DEBUG_LEAKS? or maybe combine it with valgrind or ASan? or just use ASan/valgrind?
the project has some custom derived class from vtk class

6

If you have a suspicion for a leak, enable VTK_DEBUG_LEAKS, if nothing comes up, use valgrind.

7

What is your opinion of these statements from Google AI:

If “top” shows massive memory growth while Valgrind reports very little, you are likely experiencing a “pseudo-leak”—memory that is still technically reachable (and thus not a “leak” to Valgrind) but is growing uncontrollably.
In VTK applications, this happens for three common reasons:

  1. The VTK Pipeline Cache
    VTK filters often cache their output to speed up subsequent updates. If you are running a loop that constantly updates a pipeline with new data, VTK may be holding onto every intermediate result.

    The Fix: Call ReleaseDataFlagOn() on your filters or manually call RemoveAllInputs() / UnRegister() if you are managing complex pipelines. This tells VTK it can discard data once it has been passed to the next stage.

  2. GPU/Driver “Bloat”
    Memory growth shown in top often includes memory mapped by the OpenGL/Graphics driver. Valgrind cannot see inside the driver or kernel.

    The Issue: If you are creating and destroying many vtkRenderWindow or vtkMapper objects, the driver may not be reclaiming the associated GPU buffers (like vtkBufferId) immediately.
    Verification: Try running your code in “offscreen” mode or with a software renderer (like OSMesa). If the growth disappears, the “leak” is in the driver’s management of GPU resources.

  3. Container Growth (Still Reachable)
    If you are storing VTK objects (or vtkSmartPointers) in an std::vector or std::map and forgetting to clear it, Valgrind won’t call this a “leak” because you still have a pointer to the memory.

    The Fix: Check the “Still Reachable” section of your Valgrind report. To see where these were allocated, run Valgrind with:
    –leak-check=full --show-leak-kinds=all

8

No opinion.

9

I used the valgrind heap profile tool massif on Ubuntu recently to identify where memory was being allocated and not freed when it should have been, though it was freed by program shutdown. Hence it was not technically a leak that VTK_DEBUG_LEAKS or valgrind by itself would show. See docs for it at Valgrind

1 Like
10

If I put this

#include <vtkDataObject.h>

// Call this early in your main()
vtkDataObject::GlobalReleaseDataFlagOn();

at the beginning of my program, it will still work but just be less efficient, is that right?

I have about 100 GB of RAM full of stuff that is either due to a leak or a pseudo-leak. Is there some way to switch on some VTK verbosity so that if I look at a memory dump I can figure out what these objects are? I suspect they are vtkPolyData or related things, but something like a vtkDoubleArray probably has little or no header by default, when looking at a memory dump.