Memory leaks reported in tests about slicerdmri HOT 12 OPEN

At first sight, all instances seem to stem from 3D Slicer proper; not sure how this can be tracked better. Let me know if you have some insight on this @jcfr @lassoan @jamesobutler. Thanks.

from slicerdmri.

If no memory leaks are detected without running your script, and memory leak is reported if running your script then the root cause is most likely that your script created an object without taking ownership or incremented reference count without later decrementing it. See some more information here: https://slicer.readthedocs.io/en/latest/developer_guide/advanced_topics.html#factory-methods

If it is not obvious what allocation caused the leak then you can use VTK memory leak debugging infrastructure:

https://slicer.readthedocs.io/en/latest/developer_guide/debugging/tips.html#debugging-memory-leaks

from slicerdmri.

👍 Thanks for commenting Andras.

https://slicer.readthedocs.io/en/latest/developer_guide/advanced_topics.html#factory-methods
https://slicer.readthedocs.io/en/latest/developer_guide/debugging/tips.html#debugging-memory-leaks

Interesting. Thanks for the pointers.

I'll have a better look as time permits. Thinking out loud, running a dynamic analysis tool on SlicerDMRI may be helpful.

from slicerdmri.

Attempt in PR #216 unsuccessful.

Trying to use USE_VTK_DEBUG_LEAKS:BOOL=ON () for SlicerDMRI and setting the

"environment": [{"VTK_DEBUG_LEAKS_TRACE_CLASSES": "vtkMRMLMultiVolumeRenderingDisplayNode"}],

in the VS Code launch.json does not print any line where the leak comes from.

from slicerdmri.

You need to build VTK with USE_VTK_DEBUG_LEAKS enabled.

from slicerdmri.

You need to build VTK with USE_VTK_DEBUG_LEAKS enabled.

OK. I see this now: https://github.com/Slicer/Slicer/blob/6e3288a1a0abe19576d81ba78703709e55bc4df8/CMakeLists.txt#L269

I assume this requires 3D Slicer and the extension at issue to be compiled in Debug mode, right?

from slicerdmri.

I assume this requires 3D Slicer and the extension at issue to be compiled in Debug mode, right?

No, I think this works either way.

from slicerdmri.

I think you need at least RelWithDebInfo mode to see method names and line numbers (and have the ability to debug into the code if the stack trace is not obvious enough). Debug mode makes line-by-line debugging easier (lines are executed in order, local variables are not opimized out) but execution can be much slower.

from slicerdmri.

It looks to me that USE_VTK_DEBUG_LEAKS is independent of build type. It just reports any instances there are with non-zero reference counts so it shouldn't need any symbols.

from slicerdmri.

VTK is much smarter now. It can record the stack trace of all allocations of a given class. On exit, it can print all those stack traces that belong to leaked objects. Stack trace may need symbols.

from slicerdmri.

Ah, okay, yes, that sounds helpful. It never used to do that.

from slicerdmri.

OK, thanks both for the insight.

from slicerdmri.